From owner-freebsd-current Wed Jan 17 9:23: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id EBF0237B402; Wed, 17 Jan 2001 09:22:29 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0HHL9A23321; Wed, 17 Jan 2001 09:21:09 -0800 (PST) Date: Wed, 17 Jan 2001 09:21:09 -0800 From: Alfred Perlstein To: Randell Jesup Cc: Soren Schmidt , arch@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: HEADS-UP: await/asleep removal imminent Message-ID: <20010117092109.O7240@fw.wintelcom.net> References: <200101171138.MAA11834@freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rjesup@wgate.com on Wed, Jan 17, 2001 at 11:17:29AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Randell Jesup [010117 08:14] wrote: > >It seems Alfred Perlstein wrote: > >> I have a patch here that removes await/asleep from the kernel API. > >> > >> http://people.freebsd.org/~alfred/noasleep.diff > >> > >> Matt Dillon implemented alseep/await quite some time ago and the > >> only thing that's using it is ata. In order to clean up some of > >> the schduler and vm system I'm removing support for it. > >> > >> Peter Wemm and I suspect that ata doesn't need it. Right now I'm > >> running several make -j128 buildworlds and buildkernels with this > >> patch to catch any ata problems. > > Ummmm... > > It seems to me from reading the man page for asleep/await that > they have significant utility, and that the real issue would be one of > code not using them, especially as people work to remove the Giant > lock for SMP. > > Or is the discussion in the man page wrong in some way? The manpage is correct, but we've yet to see it used properly in the code with the exception of ata, and even with ata we're not sure if it's needed. Basically the idea is that at a certain depth into the kernel you start using the M_AWAIT parameter when requesting certain resources. Since that removes the possiblity of blocking you can feel safe holding a mutex over these lower parts of the code, then only releasing your mutex later. If a resource shortage is detected then you can call await and retry later. 1) from sleep(9): to actually wait for the previously queued wait condition. If asleep() is called several times, only the most recent call is effective. asleep() may be called with an ident value of NULL to remove any previ- ously queued condition. Basically, there's a chance you may clobber previous calls to asleep, this is somewhat unlikely since most shortages or blocking when some 'NOBLOCK' flag is passed in should immediately return. Somewhat of a concern, but it really is unlikely to be a problem. 2) most things you'd use mawait for would be under a lock already, since it's under a lock, you must context switch anyway, there's no "optimized out" sleep, because first the interrupt will block on your mutex, then you'll get to run, when you drop your mutex the interrupt will then run. If you do this with msleep or masleep the effect is the same. 3) no one uses it! :) 4) most anything you need asleep for could probably be done with mutex/cv's. I'm not going to axe it for a few days, this is a really amazing API that Matt added, the problem is utility and useage over code complexity. It's just a proposal. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message