From owner-freebsd-arch@FreeBSD.ORG Sat Sep 18 23:08:37 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 F17C716A4CE for ; Sat, 18 Sep 2004 23:08:37 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 81EFD43D46 for ; Sat, 18 Sep 2004 23:08:37 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 27848 invoked by uid 89); 18 Sep 2004 23:08:35 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 18 Sep 2004 23:08:35 -0000 Received: (qmail 27822 invoked by uid 89); 18 Sep 2004 23:08:35 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 18 Sep 2004 23:08:35 -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 i8IN8Ymt043878; Sat, 18 Sep 2004 19:08:35 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: John Baldwin In-Reply-To: <200409181653.35242.jhb@FreeBSD.org> References: <1095468747.31297.241.camel@palm.tree.com> <1095529353.31297.1192.camel@palm.tree.com> <200409181653.35242.jhb@FreeBSD.org> Content-Type: text/plain Message-Id: <1095548914.43781.27.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 18 Sep 2004 19:08:34 -0400 Content-Transfer-Encoding: 7bit cc: Julian Elischer 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 23:08:38 -0000 On Sat, 2004-09-18 at 16:53, 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. Lower priority than the interrupt threads. They can however have a priority better than the interrupted thread holding the kernel resource. In this case the newly awoken threads will be next to run. If they are compute bound in user space or wake other threads with better priorities it might take a while until the system switches back to the interrupted thread. Stephan