From owner-freebsd-arch@FreeBSD.ORG Tue Sep 21 01:02:29 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 504CF16A4CE; Tue, 21 Sep 2004 01:02:29 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FC6B43D5C; Tue, 21 Sep 2004 01:02:28 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 3A2827A3E1; Mon, 20 Sep 2004 18:02:28 -0700 (PDT) Message-ID: <414F7DA3.6090409@elischer.org> Date: Mon, 20 Sep 2004 18:02:27 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin References: <1095468747.31297.241.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> <414D30EC.1000104@elischer.org> <200409201446.15278.jhb@FreeBSD.org> In-Reply-To: <200409201446.15278.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Stephan Uphoff 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: Tue, 21 Sep 2004 01:02:29 -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(). > 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.)