Date: Sat, 25 Sep 2004 14:00:20 -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: <1096135220.53798.17754.camel@palm.tree.com> In-Reply-To: <1095529353.31297.1192.camel@palm.tree.com> References: <1095468747.31297.241.camel@palm.tree.com> <1095529353.31297.1192.camel@palm.tree.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2004-09-18 at 13:42, Stephan Uphoff wrote: > On Fri, 2004-09-17 at 21:20, Julian Elischer wrote: > > Stephan Uphoff wrote: > > >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. I wrote a fix that should cover all cases. However I would like to test it a little bit before posting the patch. Is there any multi-threaded kernel torture program that you can recommend? Thanks Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1096135220.53798.17754.camel>