Date: Mon, 20 Sep 2004 18:02:27 -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: <414F7DA3.6090409@elischer.org> In-Reply-To: <200409201446.15278.jhb@FreeBSD.org> References: <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <414D30EC.1000104@elischer.org> <200409201446.15278.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >On Sunday 19 September 2004 03:10 am, Julian Elischer wrote: > > >>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 scheduler can already detect this by noting that curthread is being passed >to sched_add() when it has quantum left and then put it at the head of the >queue for its priority but only with the remaining quanta. This only really >works for schedulers that actually track quanta, i.e., not 4BSD. Given that, >I think the scheduler is free to implement this how it chooses and doesn't >require another flag to setrunqueue(). > Just for kicks I implemented this in my p4 branch to see if it would help the problem with atapi cdroms failing to work when premption is turned on.. but it didn't help.. (it's a very strange problem.. turning on preemption makes my test machine's cdrom time out so much in boot that it takes 5 minutes to probe during boot.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?414F7DA3.6090409>