DragonFly commits List (threaded) for 2005-10
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: cvs commit: src/sys/ddb db_ps.c src/sys/i386/i386 trap.c vm86.c src/sys/kern init_main.c kern_clock.c kern_exit.c kern_fork.c kern_resource.c kern_sig.c kern_synch.c kern_upcall.c lwkt_thread.c usched_bsd4.c vfs_aio.c src/sys/netproto/smb ...
: 1:1 Userland threading stage 2.8/4:
:
: Switch the userland scheduler to use lwps instead of procs.
Nice work! A few minor issues:
:http://www.dragonflybsd.org/cvsweb/src/sys/kern/init_main.c.diff?r1=1.47&r2=1.48&f=u
We want to avoid using LIST_FIRST for this case. e.g. you are doing
p = curproc;
lp = LIST_FIRST(...)
Instead of doing that, use curthread->td_lwp (assuming its set up at that point).
:http://www.dragonflybsd.org/cvsweb/src/sys/kern/kern_exit.c.diff?r1=1.46&r2=1.47&f=u
p->p_usched->heuristic_exiting(q, p);
p->p_usched->heuristic_exiting(td->td_lwp, &p->p_lwp);
Avoid using &p->p_lwp if possible, since the embedded lwp is going to go away at
some point. If this code is going to have to deal with all the LWPs then put an
XXX comment in there or do a LIST_FOREACH and/or otherwise assert that there is
only one lwp so this doesn't bite us in the ass later on.
:http://www.dragonflybsd.org/cvsweb/src/sys/kern/kern_resource.c.diff?r1=1.22&r2=1.23&f=u
Same problem, avoid using &p->p_lwp or add an XXX comment and an assertion that there
is only one thread.
- chgp->p_usched->resetpriority(chgp);
+ chgp->p_usched->resetpriority(&chgp->p_lwp);
:http://www.dragonflybsd.org/cvsweb/src/sys/kern/kern_synch.c.diff?r1=1.47&r2=1.48&f=u
Same issue (in several places):
- p->p_usched->recalculate(p);
+ p->p_usched->recalculate(&p->p_lwp);
- p->p_usched->release_curproc(p);
+ p->p_usched->release_curproc(&p->p_lwp);
- p->p_usched->remrunqueue(p);
+ p->p_usched->remrunqueue(&p->p_lwp);
:http://www.dragonflybsd.org/cvsweb/src/sys/kern/vfs_aio.c.diff?r1=1.18&r2=1.19&f=u
Same issue. Deserves a comment at least (or maybe fork should take a proc pointer,
since you can't fork an LWP anyway).
- p = &proc0;
- error = fork1(p, RFPROC|RFMEM|RFNOWAIT, &np);
+ lp = &proc0.p_lwp;
+ error = fork1(lp, RFPROC|RFMEM|RFNOWAIT, &np);
:http://www.dragonflybsd.org/cvsweb/src/sys/netproto/smb/smb_subr.c.diff?r1=1.14&r2=1.15&f=u
Same issue. I think it's becoming clear that we want fork*() to take a proc pointer.
- error = fork1(&proc0, RFMEM | RFFDG | RFPROC | flags, &p2);
+ error = fork1(&proc0.p_lwp, RFMEM | RFFDG | RFPROC | flags, &p2);
- start_forked_proc(&proc0, p2);
+ start_forked_proc(&proc0.p_lwp, p2);
:http://www.dragonflybsd.org/cvsweb/src/sys/vm/vm_glue.c.diff?r1=1.34&r2=1.35&f=u
Same issue. Add XXX comment, KKASERT that there is only one thread if accessing
&p->p_lwp.
- p->p_usched->remrunqueue(p);
+ p->p_usched->remrunqueue(&p->p_lwp);
:http://www.dragonflybsd.org/cvsweb/src/sys/vm/vm_pageout.c.diff?r1=1.14&r2=1.15&f=u
:
Same issue.
- bigproc->p_usched->resetpriority(bigproc);
+ bigproc->p_usched->resetpriority(&bigproc->p_lwp);
Why is this important? Even though these steps are intermediate steps and
will undergo further changes, we do not want the complexity of the work to introduce
bugs as it progresses. It is better to assert the assumed condition in the intermediate
step and take a panic later on when you've forgotten something than for the system
to become corrupt and take hours to debug.
-Matt
Matthew Dillon
<dillon@xxxxxxxxxxxxx>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]