Date: Sat, 7 Jul 2001 21:13:44 -0500 From: Alfred Perlstein <bright@sneakerz.org> To: Greg Lehey <grog@FreeBSD.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: <20010707211344.I88962@sneakerz.org> In-Reply-To: <20010708110449.E75626@wantadilla.lemis.com>; from grog@FreeBSD.org on Sun, Jul 08, 2001 at 11:04:49AM %2B0930 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>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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. :) 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. And you didn't credit me in the commit message. :) Currently wakeup_one() is broken in several ways, if fixed it may work better. Problems: 1) it doesn't wakeup the highest priority process, this can be easily fixed. 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. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? 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?20010707211344.I88962>