On Sat, 20 Jan 2007, Andrew Doran wrote:

(thanks for the explanation btw :)

> CPU1: ltsleep()   -> acquire sched_lock    -> spin on callout_slock
> CPU2: softclock() -> acquire callout_slock -> spin on sched_lock
>
> Maybe another lock could be used to protect the timeout_work queue. I'm not
> sure how that might look.

An extra lock won't change anything I think, because it still needs to be
taken to safely unlink the callout. I looked (superficially) at that
before.

of the two calls, the wakeup() is not a problem since we can just
CALLOUT_UNLOCK/CALLOUT_LOCK around it.

the ltsleep() is more problematic since I don't want to leave a gap where
another callout can be inserted on the queue, and unlocking the
callout_slock (without splx()) would allow another CPU to do that, yes?

I think the only way this can be integrated cleanly then would be to
extend the callout structure with a separate link entry, because the
callout lock is needed to safely access the one we have. But then, I
think, the overheads start becoming significant which is not likely a good
idea.

iain