On Wed, Dec 19, 2007 at 11:44:00AM -0800, Julian Elischer wrote: > David G Lawrence wrote: > >>> In any case, it appears that my patch is a no-op, at least for the > >>>problem I was trying to solve. This has me confused, however, because at > >>>one point the problem was mitigated with it. The patch has gone through > >>>several iterations, however, and it could be that it was made to the top > >>>of the loop, before any of the checks, in a previous version. Hmmm. > >>The patch should work fine. IIRC, it yields voluntarily so that other > >>things can run. I committed a similar hack for uiomove(). It was > > > > It patches the bottom of the loop, which is only reached if the vnode > >is dirty. So it will only help if there are thousands of dirty vnodes. > >While that condition can certainly happen, it isn't the case that I'm > >particularly interested in. > > > >>CPUs, everything except interrupts has to wait for these syscalls. Now > >>the main problem is to figure out why PREEMPTION doesn't work. I'm > >>not working on this directly since I'm running ~5.2 where nearly-full > >>kernel preemption doesn't work due to Giant locking. > > > > I don't understand how PREEMPTION is supposed to work (I mean > >to any significant detail), so I can't really comment on that. > > It's really very simple. > > When you do a "wakeup" > (or anything else that puts a thread on a run queue) > i.e. use setrunqueue() > then if that thread has more priority than you do, (and in the general case > is an interrupt thread), you immedialty call mi_switch so that it runs > imediatly. > You get guaranteed to run again when it finishes. > (you are not just put back on the run queue at the end). As far as I see it, only the interrupt threads can put the kernel thread off the CPU. More, the thread being forced out shall be an "idle user thread".
See kern_switch.c, maybe_preempt(), the #ifndef FULL_PREEMPTION block. > > the critical_enter()/critical_exit() calls disable this from happening to > you if you really must not be interrupted by another thread. > > there is an option where it is not jsut interrupt threads that can jump in, > but I think it's usually disabled. Do you mean FULL_PREEMPTION ?
pgp9yoTTNhHmz.pgp
Description: PGP signature