Date: Sat, 18 Sep 2004 13:42:33 -0400 From: Stephan Uphoff <ups@tree.com> To: Julian Elischer <julian@elischer.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: scheduler (sched_4bsd) questions Message-ID: <1095529353.31297.1192.camel@palm.tree.com> In-Reply-To: <414B8D5E.7000700@elischer.org> References: <1095468747.31297.241.camel@palm.tree.com> <414B8D5E.7000700@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ... > > > The theory is however that as long as the CPU is doing something, teh > throughput is > still being maintianed. Mhhh .. yes - I guess the only problem is with pathetic cases. ( Tons of cpu bound threads and nice values that prevent the preempted thread to gain a better priority) > (For this reason we have not worked on the > problem you mention yet, though > it will eventually get to the top of someone's list :-) Great > > > >I am also stomped by the special case of adding a thread X with better > >priority than the current thread to the runqueue if they belong to the > >same ksegroup. In this case both kg_last_assigned and kg_avail_opennings > >might be zero and setrunqueue() will not call sched_add(). > >Because of this it looks like the current thread will neither be > >preempted not will TDF_NEEDRESCHED be set to force rescheduling at the > >kernel boundary. > >This situation should resolve itself at the next sched_switch - however > >this might take a long time. (Especially if essential interrupt threads > >are blocked by mutexes held by thread X) > > > > you are correct. I am not yet preempting a running thread with a lesser > priority if they are siblings > (unless there is a slot available) Thsi is not becasue I don't want to > do it, but simply because it has not been done yet.. > we did have NO preemption, so having "some" preemption is still better > than where we were. > Special case code to check curthread for a preemption could be done but > at the moment the decision code for > whether to preempt or not is in maybe_preempt() and I don't want to > duplicate that. it is on th edrawing board though. > The other thing is, that even if we should be able to preempt a running > thread, there is no guarantee that it is on THIS > CPU. It may be on another CPU and that gets nasty in a hurry. Yes .. this could get nasty. This happens when the thread is bound to another cpu or someone changed thr_concurrency - otherwise the current thread must be a sibling right ? Maybe something brutal like: if ((curthread->td_ksegrp == kg) && (td->td_priority > curthread->td_priority)) curthread->td_flags |= TDF_NEEDRESCHED; in setrunqueue for the else case of "if (kg->kg_avail_opennings > 0)" would do the trick (without preemption) for the easy but probably more common cases? Maybe I can find some time next week to think about a clean fix. I find it always helpful having a small task in mind while reading source code. > >PS: I am impressed how clean and easy to read the scheduler sources are. > > Looks like a lot of hard work went into this. > > > > There is a lot to clean up yet.. But there is a huge difference between thinking about a little vacuuming and wishing for some bulldozers ;-) > what version are you reading? -current? current (Sep 16) Thanks for the detailed answer. Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1095529353.31297.1192.camel>