Date: Mon, 7 Aug 2000 01:50:18 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Stephen McKay <mckay@thehub.com.au>, freebsd-current@FreeBSD.ORG, dillon@FreeBSD.ORG Subject: Re: Ugly, slow shutdown Message-ID: <20000807015018.R4854@fw.wintelcom.net> In-Reply-To: <200008070836.BAA02380@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Mon, Aug 07, 2000 at 01:36:57AM -0700 References: <20000807011854.Q4854@fw.wintelcom.net> <200008070836.BAA02380@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Mike Smith <msmith@FreeBSD.ORG> [000807 01:25] wrote: > > * 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" > > Actually, that depends. It is definitely poor programming practice to > not check the condition for which you slept on wakeup. Stephen's patches didn't give them that option, the syncer could be in some other part of vfs that doesn't expect to be woken up, perhaps in uniterruptable sleep... perhaps waiting for a DMA transfer? How does one check if the data filled into a buffer is actually from the driver and not just stale? > > *boom* *crash* *ow* :) > > Doctor: So don't do that. > > In this case, the relevant processes just need to learn to check whether > they've been woken in order to die. No, they need to signify that it's safe to wake them up early. -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?20000807015018.R4854>
