Date: Sun, 8 Jul 2001 14:30:50 +0930 From: Greg Lehey <grog@FreeBSD.org> To: Alfred Perlstein <bright@sneakerz.org> Cc: Matt Dillon <dillon@earth.backplane.com>, "Justin T. Gibbs" <gibbs@scsiguy.com>, John Baldwin <jhb@FreeBSD.org>, Jake Burkholder <jake@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Matthew Jacob <mjacob@feral.com>, Doug Rabson <dfr@nlsystems.com> Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Message-ID: <20010708143050.X80862@wantadilla.lemis.com> In-Reply-To: <20010707211344.I88962@sneakerz.org>; from bright@sneakerz.org on Sat, Jul 07, 2001 at 09:13:44PM -0500 References: <XFMail.010705123747.jhb@FreeBSD.org> <200107052228.f65MSeU64741@aslan.scsiguy.com> <20010705174135.A79818@sneakerz.org> <200107060214.f662ElT61708@earth.backplane.com> <20010708110449.E75626@wantadilla.lemis.com> <20010707211344.I88962@sneakerz.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, 7 July 2001 at 21:13:44 -0500, Alfred Perlstein wrote: > * Greg Lehey <grog@FreeBSD.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010708143050.X80862>