From owner-freebsd-arch@FreeBSD.ORG Mon Oct 4 18:49:44 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 D8AA916A4CF for ; Mon, 4 Oct 2004 18:49:44 +0000 (GMT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 533D843D53 for ; Mon, 4 Oct 2004 18:49:44 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 50983 invoked from network); 4 Oct 2004 18:49:40 -0000 Received: from 0x50a43fc7.hknxx1.adsl-dhcp.tele.dk (HELO peter.osted.lan) (80.164.63.199) by relay.pair.com with SMTP; 4 Oct 2004 18:49:40 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.12.10/8.12.10) with ESMTP id i94IndEe008279; Mon, 4 Oct 2004 20:49:39 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.12.10/8.12.10/Submit) id i94IndYK008278; Mon, 4 Oct 2004 20:49:39 +0200 (CEST) (envelope-from pho) Date: Mon, 4 Oct 2004 20:49:39 +0200 From: Peter Holm To: Stephan Uphoff Message-ID: <20041004184939.GA8178@peter.osted.lan> References: <1095468747.31297.241.camel@palm.tree.com> <1096496057.3733.2163.camel@palm.tree.com> <1096603981.21577.195.camel@palm.tree.com> <200410041131.35387.jhb@FreeBSD.org> <1096911278.44307.17.camel@palm.tree.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096911278.44307.17.camel@palm.tree.com> User-Agent: Mutt/1.4.1i 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: Mon, 04 Oct 2004 18:49:45 -0000 On Mon, Oct 04, 2004 at 01:34:38PM -0400, 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. I'm not closer to being able to create this panic in a controlled way. After a whole day of different tests I finally got this panic: http://www.holm.cc/stress/log/cons81.html. The trigger seems to be one particular Java applet, but it is not easily reproduceable. - Peter > > > If the interrupt happens before x is released, > > then the final bit of propagate_priority() should handle it since it resorts > > the turnstile's thread queue so that C will be awakened rather than B. > > Agreed. > > Stephan