Re: Re: [PATCH] [RFC] Credit2 scheduler prototype

[George Dunlap <george.dunlap@eu.citrix.com>]

Keir Fraser wrote:
> On 13/01/2010 16:05, "George Dunlap" <George.Dunlap@eu.citrix.com> 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).
>   
Hmm.... can't see anything wrong with it.  It would make the whole 
locking discipline thing a lot simpler.  It would, AFAICT, remove the 
need for private per-runqueue locks, which make it a lot harder to avoid 
deadlock without these sorts of strange tricks. :-)

I'll think about it, and probably give it a spin to see how it works out.

 -George