Date: Sun, 19 Sep 2004 00:10:36 -0700 From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: scheduler (sched_4bsd) questions Message-ID: <414D30EC.1000104@elischer.org> In-Reply-To: <200409181653.35242.jhb@FreeBSD.org> References: <1095468747.31297.241.camel@palm.tree.com> <414B8D5E.7000700@elischer.org> <1095529353.31297.1192.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. though that may still be before the original preempted thread gets run.. that reminds me.. John, we should add a flag to setrunqueue to add a preempted thread back at the FRONT of it's runqueue.. So that it gets a chance to use the rest of its slot.. the alternative is to keep a special "stack" (per cpu) of preempted threads so that we come back to the thread that we preempted.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?414D30EC.1000104>