* 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()
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
