From owner-freebsd-arch@FreeBSD.ORG Thu Mar 20 02:31:40 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1936106566B; Thu, 20 Mar 2008 02:31:40 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 91ED88FC14; Thu, 20 Mar 2008 02:31:40 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m2K2VVF1028455; Wed, 19 Mar 2008 22:31:36 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 19 Mar 2008 16:32:28 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Daniel Eischen In-Reply-To: Message-ID: <20080319162928.V910@desktop> References: <20080307020626.G920@desktop> <20080318235125.G910@desktop> <20080319172344.GX67856@elvis.mu.org> <200803191526.56761.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Alfred Perlstein , David Xu , freebsd-arch@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 02:31:41 -0000 On Wed, 19 Mar 2008, Daniel Eischen wrote: > On Wed, 19 Mar 2008, John Baldwin wrote: > >> On Wednesday 19 March 2008 01:23:44 pm Alfred Perlstein wrote: >>> * Jeff Roberson [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? >> >> Right now we let people invoke cv_wakeup/signal w/o holding the lock. I >> actually took the thread queue out of condvar's back when doing the >> original >> sleep queue stuff since it is cheaper space wise. Instead of each possible >> condvar having its own set of queue pointers you just have a set of queue >> pointers for each thread in the system. Similar to only have a turnstile >> per >> thread rather than per lock. > > In regards to why should we use cv_wait() instead of msleep()'s, the > mutex/cv operations are more POSIX/pthreads-like with a simpler > set of arguments. Solaris for example does not have msleep() nor > anything like that I can see, it uses similar mutex/cv operations > as part of its kernel ABI (DDI/DKI). I don't think there is a problem > in allowing cv_signal() to be called without holding the lock, but > it's nice that cv_wait() requires the lock - this is the same > behavior as in pthreads and Solaris primitives. > > Perhaps there are no performance differences, but the cv/mutex > primitives are a nice clean interface that most everyone > understands. If you are going to write a professional OS from > the ground up, I doubt you are going to have anything as convoluted > as msleep() as part of your kernel API/ABI. One real obstacle to converting all locations to cv_* is the lack of support for anything other than mtx def mutexes in the cv api. It also just doesn't seem like a good use of developer resources regardless of how you feel about msleep. Also, in regards to interlocking with the user supplied lock; the lock that we interlock with for scheduling purposes must be a spinlock. Therefore we can't use just any user supplied lock to protect the sleepq chain. Thanks, Jeff > > -- > DE >