From owner-freebsd-arch@FreeBSD.ORG Mon Sep 20 20:12:00 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 F391716A4CF for ; Mon, 20 Sep 2004 20:11:59 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id C51D243D5C for ; Mon, 20 Sep 2004 20:11:59 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30945 invoked from network); 20 Sep 2004 20:11:59 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 20 Sep 2004 20:11:58 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8KKBt4e025478; Mon, 20 Sep 2004 16:11:55 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Mon, 20 Sep 2004 14:46:15 -0400 User-Agent: KMail/1.6.2 References: <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <414D30EC.1000104@elischer.org> In-Reply-To: <414D30EC.1000104@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409201446.15278.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Julian Elischer cc: Stephan Uphoff 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: Mon, 20 Sep 2004 20:12:00 -0000 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(). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org