From owner-freebsd-arch@FreeBSD.ORG Mon Oct 4 20:28:42 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 EC91F16A4D3 for ; Mon, 4 Oct 2004 20:28:41 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8E1F43D48 for ; Mon, 4 Oct 2004 20:28:41 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 14822 invoked from network); 4 Oct 2004 20:28:41 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Oct 2004 20:28:40 -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 i94KSU5n058953; Mon, 4 Oct 2004 16:28:37 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Mon, 4 Oct 2004 14:03:06 -0400 User-Agent: KMail/1.6.2 References: <1095468747.31297.241.camel@palm.tree.com> <200410041131.35387.jhb@FreeBSD.org> <1096911278.44307.17.camel@palm.tree.com> In-Reply-To: <1096911278.44307.17.camel@palm.tree.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410041403.06187.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Peter Holm cc: "freebsd-arch@freebsd.org" 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, 04 Oct 2004 20:28:42 -0000 On Monday 04 October 2004 01:34 pm, Stephan Uphoff wrote: > On Mon, 2004-10-04 at 11:31, John Baldwin wrote: > > On Friday 01 October 2004 12:13 am, Stephan Uphoff wrote: > > > On Wed, 2004-09-29 at 18:14, Stephan Uphoff wrote: > > > > I was looking at the MUTEX_WAKE_ALL undefined case when I used the > > > > critical section for turnstile_claim(). > > > > However there are bigger problems with MUTEX_WAKE_ALL undefined > > > > so you are right - the critical section for turnstile_claim is pretty > > > > useless. > > > > > > Arghhh !!! > > > > > > MUTEX_WAKE_ALL is NOT an option in GENERIC. > > > I recall verifying that it is defined twice. Guess I must have looked > > > at the wrong source tree :-( > > > This means yes - we have bigger problems! > > > > > > Example: > > > > > > Thread A holds a mutex x contested by Thread B and C and has priority > > > pri(A). > > > > > > Thread C holds a mutex y and pri(B) < pri(C) > > > > > > Thread A releases the lock wakes thread B but lets C on the turnstile > > > wait queue. > > > > > > An interrupt thread I tries to lock mutex y owned by C. > > > > > > However priority inheritance does not work since B needs to run first > > > to take ownership of the lock. > > > > > > I is blocked :-( > > > > Ermm, if the interrupt happens after x is released then I's priority > > should propagate from I to C to B. > > There is a hole after the mutex x is released by A - but before B can > claim the mutex. The turnstile for mutex x is unowned and interrupt > thread I when trying to donate its priority will run into: > > if (td == NULL) { > /* > * This really isn't quite right. Really > * ought to bump priority of thread that > * next acquires the lock. > */ > return; > } > > So B needs to run and acquire the mutex before priority inheritance > works again and does not get a priority boost to do so. > > This is easy to fix and MUTEX_WAKE_ALL can be removed again at that time > - but my time budget is limited and Peter has an interesting bug left > that has priority. Isn't this handled by the mtx_lock == MTX_CONTESTED case that calls into turnstile_claim() which bumps the priority of the new owner to the highest priority waiting thread? I guess this won't happen until B gets to run again which is the problem. You don't know which thread is going to get the lock, so what do you do? You don't even have a way to get to the threads that you might have just woken up. BTW, Solaris uses MUTEX_WAKE_ALL by default, but for performance reasons. It is a kernel option because the idea was to benchmark it both ways and then choose the default based on those numbers. It's off by default as the wake-one was the original behavior. I'm pretty sure BSD/OS has this same issue. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org