On 13/01/2010 16:05, "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx> wrote:
> [NB that the current global lock will eventually be replaced with
> per-runqueue locks.]
>
> In particular, one of the races without the first flag looks like this
> (brackets indicate physical cpu):
> [0] lock cpu0 schedule lock
> [0] lock credit2 runqueue lock
> [0] Take vX off runqueue; vX->processor == 1
> [0] unlock credit2 runqueue lock
> [1] vcpu_wake(vX) lock cpu1 schedule lock
> [1] finds vX->running false, adds it to the runqueue
> [1] unlock cpu1 schedule_lock
Actually, hang on. Doesn't this issue, and the one that your second patch
addresses, go away if we change the schedule_lock granularity to match
runqueue granularity? That would seem pretty sensible, and could be
implemented with a schedule_lock(cpu) scheduler hook, returning a
spinlock_t*, and a some easy scheduler code changes.
If we do that, do you then even need separate private per-runqueue locks?
(Just an extra thought).
 -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel