From owner-freebsd-alpha Tue Jan 2 13: 8:47 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 13:08:45 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id AF29337B400; Tue, 2 Jan 2001 13:08:44 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA22415; Tue, 2 Jan 2001 13:08:41 -0800 Date: Tue, 2 Jan 2001 13:08:40 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: John Baldwin , alpha@FreeBSD.ORG, Doug Rabson Subject: RE: Interrupt threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > On Tue, 2 Jan 2001, Matthew Jacob wrote: > > > You switch to the process w/o changing IPL. It is resumed at the IPL of the > > ithread that blocked. In the software way of looking at it, it inherits the > > priority of the ithread until it releases the lock that caused it to be > > resumed. > > Just a tiny question and remark: > > We must keep in mind (at it I have this in mind) that IPL is a thing local > to a CPU but MUTEXes are global synchronisation objects. That's absolutely correct. > What happens if a ithread want to acquire a MUTEX owned by a thread > running on another CPU ? > > In my $0.02 humble opinion, I think that we should probably be able from > an ithread to just spinlock on a MUTEX that is already owned, unless we > are believing in miracles. This is why Solaris (and FreeBSD) makes a distinction between Spin and Adaptive locks. The default we have for all of this are adaptive locks- the ithread that tries to snag a lock that's held elsewhere will cause a reschedule. For a single CPU case, the thread that holds the lock should be resumed so the lock can be freed up as soon as possible. For the multiple CPU case, a spin should occur. The net result is the same- the ithread wanting the lock that's held elsewhere has to wait until that lock is clear. We've been fussing mostly over the issue that interrupt passivating doesn't seem to occur as cleanly as we'd like on all platforms. What will help get rid of the awful inefficiencies that this will bring in will be the active rewriting of drivers to choose locking strategies that will avoid this. We're very early in this stage so that we have broad swaths where things Just Don't Work Well(tm). > > > > > 4. What defeated me immediately upon looking at Doug's stuff is all of the > > > > thread pri seems to be a software construct, so has no real hardware > > > > linkage. Additionally, I did not take the time to try and find an easy way to > > > > find and reschdule the proc that holds a lock if I'm trying to acquire it > > > > from > > > > an ithread and am blocking. Seems to be a bit of work there. > > IMO, the real issue is pointed here. I don't understand this. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message