From owner-freebsd-arch@FreeBSD.ORG  Wed Mar 19 17:25:08 2008
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: arch@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 86E7F1065672;
	Wed, 19 Mar 2008 17:25:08 +0000 (UTC)
	(envelope-from bright@elvis.mu.org)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.freebsd.org (Postfix) with ESMTP id 7A8498FC17;
	Wed, 19 Mar 2008 17:25:08 +0000 (UTC)
	(envelope-from bright@elvis.mu.org)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id E81231A4D7E; Wed, 19 Mar 2008 10:23:44 -0700 (PDT)
Date: Wed, 19 Mar 2008 10:23:44 -0700
From: Alfred Perlstein <alfred@freebsd.org>
To: Jeff Roberson <jroberson@chesapeake.net>
Message-ID: <20080319172344.GX67856@elvis.mu.org>
References: <20080307020626.G920@desktop>
	<Pine.GSO.4.64.0803071114100.1950@sea.ntplx.net>
	<47E0CCC4.8040503@freebsd.org> <20080318235125.G910@desktop>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080318235125.G910@desktop>
User-Agent: Mutt/1.4.2.3i
Cc: Daniel Eischen <deischen@FreeBSD.org>, arch@FreeBSD.org,
	David Xu <davidxu@FreeBSD.org>
Subject: Re: Getting rid of the static msleep priority boost
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2008 17:25:08 -0000

* Jeff Roberson <jroberson@chesapeake.net> [080319 02:51] wrote:
> On Wed, 19 Mar 2008, David Xu wrote:
> 
> >Daniel Eischen wrote:
> >
> >>I'm not sure if any of the above remove the priority from the API,
> >>but it would be nice to get rid of msleep totally and replace it
> >>with an equivalent cv_wait().
> >>
> >
> >And create sleep queue in each cv to get rid of shared sleep queue
> >lock ?
> 
> Some spinlock is required to interlock with the scheduler lock via 
> thread_lock().  So I don't think you can get rid of that layer.  You also 
> wouldn't want to have the cost of a 'struct sleepqueue' everywhere you 
> want a msleep/condvar.
> 
> I personally don't see any real advantage to using condvar everywhere. 
> The only thing you really get is protection against spurious wakeups.

In theory can't you protect the waitq hung off of condvars with
the mutex/spinlock used for the condvar instead of a global 
(hashed) lock on the global waitq?

(although doing a condvar_signal/broadcast without the lock
 would require that the internal code reacquire the lock)

-- 
- Alfred Perlstein