From owner-freebsd-current  Mon Aug  7  1:19: 7 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5666B37BD2B; Mon,  7 Aug 2000 01:19:03 -0700 (PDT)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e778Isr25292;
	Mon, 7 Aug 2000 01:18:54 -0700 (PDT)
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>
References: <200008051549.BAA10791@dungeon.home>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <200008051549.BAA10791@dungeon.home>; from mckay@thehub.com.au on Sun, Aug 06, 2000 at 01:49:49AM +1000
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* 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