[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-kern
Subject:    Re: timedwork
From:       Iain Hibbert <plunky () rya-online ! net>
Date:       2007-01-21 9:45:47
Message-ID: 1169372747.721273.1530.nullmailer () galant ! ukfsn ! org
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]