From owner-freebsd-arch@FreeBSD.ORG Sat Sep 18 17:42:36 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C3A216A4CE for ; Sat, 18 Sep 2004 17:42:36 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 219F043D1F for ; Sat, 18 Sep 2004 17:42:36 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 26260 invoked by uid 89); 18 Sep 2004 17:42:35 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 18 Sep 2004 17:42:35 -0000 Received: (qmail 26249 invoked by uid 89); 18 Sep 2004 17:42:34 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 18 Sep 2004 17:42:34 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8IHgXmt042638; Sat, 18 Sep 2004 13:42:34 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Julian Elischer In-Reply-To: <414B8D5E.7000700@elischer.org> References: <1095468747.31297.241.camel@palm.tree.com> <414B8D5E.7000700@elischer.org> Content-Type: text/plain Message-Id: <1095529353.31297.1192.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 18 Sep 2004 13:42:33 -0400 Content-Transfer-Encoding: 7bit cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 17:42:36 -0000 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