Date: Mon, 7 Aug 2000 01:18:54 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Stephen McKay <mckay@thehub.com.au> Cc: freebsd-current@FreeBSD.ORG, dillon@FreeBSD.ORG Subject: Re: Ugly, slow shutdown Message-ID: <20000807011854.Q4854@fw.wintelcom.net> In-Reply-To: <200008051549.BAA10791@dungeon.home>; from mckay@thehub.com.au on Sun, Aug 06, 2000 at 01:49:49AM %2B1000 References: <200008051549.BAA10791@dungeon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
* Stephen McKay <mckay@thehub.com.au> [000805 08:49] wrote: > > Patch 2 is smaller and possibly controversial. Normally bufdaemon and > syncer are sleeping when they are told to suspend. This delays shutdown > by a few boring seconds. With this patch, it is zippier. I expect people > to complain about this shortcut, but every sleeping process should expect > to be woken for no reason at all. Basic kernel premise. You better bet it's controversial, this isn't "Basic kernel premise" it's quite possible and acceptable for some piece of code to expect this sequence: me someone else put myself at the head of a queue waiting for some resource finish with resource and perform wakeup assume wakeup was notification of resource availability and use it without checking for a 'stray' wakeup. *boom* *crash* *ow* :) > I've been running these patches on a 4.x machine for a while now. No > problems except I am now surprised by the slow and ugly shutdown of > unpatched machines. :-) If you want to speed it up "properly" then either set up some protocol or do something along the lines of what speedup_syncer() does: if (updateproc->p_wchan == &lbolt) setrunnable(updateproc); It 'knows' that the syncer is safe to wakeup when sleeping on lbolt (only) and only wakes it up then, otherwise it may be in some other random part of vfsbio and blow up. but... Actually I think that speedup_syncer() is somewhat bogus and should also check some sort of variable that says "syncer is idle" rather than lbolt, because we never know when an lbolt sleep may happen in the codepath. (ugh) The syncer would need to set this variable before sleeping to declare itself "safe" for per-emptive wakeup. It's a bit of hysteria but it's definetly possible. hope this helps, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000807011854.Q4854>