scheduler (sched_4bsd) questions

John Baldwin jhb at FreeBSD.org
Mon Sep 20 11:41:53 PDT 2004


On Saturday 18 September 2004 07:08 pm, Stephan Uphoff wrote:
> On Sat, 2004-09-18 at 16:53, John Baldwin wrote:
> > On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote:
> > > On Fri, 2004-09-17 at 21:20, Julian Elischer wrote:
> > > > Stephan Uphoff wrote:
> > > > >If this is true kernel threads can be preempted while holding
> > > > >for example the root vnode lock (or other important kernel
> > > > >resources) while not getting a chance to run until there are no more
> > > > >user processes with better priority.
> > > >
> > > > This is also true,  though it is a slightly more complicated thing
> > > > than that.
> > > > Preempting threads are usually interrupt threads and are thus usually
> > > > short lived,.
> > >
> > > But interrupt threads often wake up other threads ...
> >
> > That are lower priority and thus won't be preempted to.  Instead, they
> > run when the interrupt thread goes back to sleep after it finishes.
>
> Lower priority than the interrupt threads.
> They can however have a priority better than the interrupted thread
> holding the kernel resource.
> In this case the newly awoken threads will be next to run.
> If they are compute bound in user space or wake other threads with
> better priorities it might take a while until the system switches back
> to the interrupted thread.

Yes, but that is what the system is supposed to do.  If you want the 
interrupted thread to run sooner because it holds a resource, then you need 
to adjust its priority when it holds the resource somehow.  We do this with 
mutexes by having a blocking thread lend its priority to the owner of the 
mutex.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the freebsd-arch mailing list