Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Sep 2004 14:42:04 -0400
From:      John Baldwin <jhb@FreeBSD.org>
To:        Stephan Uphoff <ups@tree.com>
Cc:        "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org>
Subject:   Re: scheduler (sched_4bsd) questions
Message-ID:  <200409201442.04525.jhb@FreeBSD.org>
In-Reply-To: <1095548914.43781.27.camel@palm.tree.com>
References:  <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <1095548914.43781.27.camel@palm.tree.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409201442.04525.jhb>