* Stephen McKay <[EMAIL PROTECTED]> [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()

        if (updateproc->p_wchan == &lbolt)

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.


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,

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to