From owner-cvs-all Sat Jul 7 22: 1: 2 2001 Delivered-To: cvs-all@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id B9D8B37B403; Sat, 7 Jul 2001 22:00:52 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 936906ACC1; Sun, 8 Jul 2001 14:30:50 +0930 (CST) Date: Sun, 8 Jul 2001 14:30:50 +0930 From: Greg Lehey To: Alfred Perlstein Cc: Matt Dillon , "Justin T. Gibbs" , John Baldwin , Jake Burkholder , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Matthew Jacob , Doug Rabson Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Message-ID: <20010708143050.X80862@wantadilla.lemis.com> References: <200107052228.f65MSeU64741@aslan.scsiguy.com> <20010705174135.A79818@sneakerz.org> <200107060214.f662ElT61708@earth.backplane.com> <20010708110449.E75626@wantadilla.lemis.com> <20010707211344.I88962@sneakerz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010707211344.I88962@sneakerz.org>; from bright@sneakerz.org on Sat, Jul 07, 2001 at 09:13:44PM -0500 Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday, 7 July 2001 at 21:13:44 -0500, Alfred Perlstein wrote: > * Greg Lehey [010707 20:34] wrote: >> On Thursday, 5 July 2001 at 19:14:47 -0700, Matt Dillon wrote: >>> >>>> Y'know this sorta got me thinking about something else, shouldn't the >>>> wakeup() calls for most exclusive locks use wakeup_one? I know >>>> wakeup_one() hoses priority, but for the locks in things like vnodes >>>> and the pager locks, shouldn't we do a wakeup_one() since it is an >>>> exclusive lock? >>> >>> I would not recommend using wakeup_one until 5.2ish. A mistake could >>> result in hard-to-find system lockups. >> >> I would not recommend using wakeup_one. It has the potential to hang >> the system. >> >> One of the tradeoffs in the sleep/wakeup paradigm is that you wait on >> an arbitrary address. This works fine as long as you wake up *every* >> process. But consider two independent subsystems which wait on the >> same address. wakeup_one wakes the first waiter on the list, which >> happens to belong to the other subsystem. It checks its environment >> and goes back to sleep. Bingo! The first subsystem has lost a >> wakeup. >> >> This isn't a theoretical situation: it happened in Vinum. The >> solution is to guarantee that two subsystems don't wait on the same >> address. I don't see that this is addressed by the current condition >> variable implementation, but I'm prepared to be taught otherwise. >> >> In this connection, more on the Vinum implementation: the code is in >> lockrange() in vinumlock.c. It implements locking for a potentially >> very large number of bands in a RAID-5 volume, and it sleeps on the >> band address. The only alternative I can see at the moment is to >> create a large number of mutex locks, one per band, which could be >> very expensive. If anybody has a better idea after looking at the >> code, I'd be interested. > > Greg, I know. :) I know you know. > It was me that diagnosed the problem and told you that wakeup_one() > was innapropriate for your useage. You're reiterating what I > explained on irc. Sure, but you didn't say this. I was replying to your message, but it was really for the benefit of others. > And you didn't credit me in the commit message. :) Oops, mea culpa. > Currently wakeup_one() is broken in several ways, if fixed it may > work better. I don't think you can fix the problem in question. > Problems: > 1) it doesn't wakeup the highest priority process, this can be > easily fixed. Yes. > 2) any processes it comes across that are swapped out are woken > up. this is to avoid letting processes die, however it makes > for a rude suprise especially when you have dozens of apache > processes swapped out waiting on thier listening socket, it > effectively causes much pain as thrashing starts and the > machine goes down in a firery death. > the solution is to implement a max on the number of swapped > out processes that wakeup_one will swap in, and keep it somewhat > low. Hmm. I hadn't noticed that before. In any case, as long as unrelated processes can sleep on the same address, wakeup_one is broken, and it shouldn't be used. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message