From owner-freebsd-arch@FreeBSD.ORG Thu Sep 30 18:30:56 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 1C29016A4CE for ; Thu, 30 Sep 2004 18:30:56 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 7232643D48 for ; Thu, 30 Sep 2004 18:30:55 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 2097 invoked by uid 89); 30 Sep 2004 18:30:53 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 30 Sep 2004 18:30:53 -0000 Received: (qmail 2076 invoked by uid 89); 30 Sep 2004 18:30:53 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 30 Sep 2004 18:30:53 -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 i8UIUpmt022172; Thu, 30 Sep 2004 14:30:52 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: John Baldwin In-Reply-To: <200409301017.54350.jhb@FreeBSD.org> References: <1095468747.31297.241.camel@palm.tree.com> <200409291652.29990.jhb@FreeBSD.org> <1096496057.3733.2163.camel@palm.tree.com> <200409301017.54350.jhb@FreeBSD.org> Content-Type: text/plain Message-Id: <1096569051.21577.23.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 30 Sep 2004 14:30:51 -0400 Content-Transfer-Encoding: 7bit cc: Peter Holm 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: Thu, 30 Sep 2004 18:30:56 -0000 On Thu, 2004-09-30 at 10:17, John Baldwin wrote: > Fair enough. The right place to fix this is in turnstile_unpend() though I > think. I have had these patches that try to "clump" setrunqueue's before > preempting lying around (but not thoroughly tested yet) that might fix this > as well but in the turnstile code itself: - snip - > --- //depot/projects/smpng/sys/kern/subr_turnstile.c 2004/09/03 14:14:21 > +++ //depot/user/jhb/preemption/kern/subr_turnstile.c 2004/09/10 21:36:10 > @@ -727,6 +726,7 @@ > * in turnstile_wait(). Set a flag to force it to try to acquire > * the lock again instead of blocking. > */ > + critical_enter(); > while (!TAILQ_EMPTY(&pending_threads)) { > td = TAILQ_FIRST(&pending_threads); > TAILQ_REMOVE(&pending_threads, td, td_lockq); > @@ -742,6 +742,7 @@ > MPASS(TD_IS_RUNNING(td) || TD_ON_RUNQ(td)); > } > } > + critical_exit(); > mtx_unlock_spin(&sched_lock); > } -snip - > > I.e., you could just move the critical_enter() in subr_turnstile.c earlier so > it is before the mtx_unlock_spin() of the turnstile chain lock. I agree - this would be the right place. I was originally planning to do some more work in kern_mutex and did not want to touch more than one file ;-) Can you check this in? Your other patches look like they are targeted to avoid senseless switching to improve performance - but should not have an impact on correct function. Right ? Hopefully I get some time to look at them more closely later on. Stephan