Re: [RFC][PATCH] Scheduler interface changes for credit2

[Keir Fraser <keir.fraser@eu.citrix.com>]

They're all fine, even probably sched-context_switch-callback.diff, which I
suppose is your new alternative to having vcpus-which-arent-yet-schedulable
left on the shared runqueue? I suppose, although I reckon it could still be
done another way and using the vcpu_migrate logic, that this is a smaller
and neater way to do it really.

All this are apply-able after 4.0.

 -- Keir

On 22/02/2010 15:22, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

> Keir, any thoughts?  Does this seem like a reasonable approach?
> 
> Thanks,
>  -George
> 
> On Mon, Feb 15, 2010 at 5:20 PM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
>> The two attached patches change the scheduler interface to allow
>> credit2 to have several cpus share the same runqueue.  The patches
>> should have almost no impact on the current schedulers.  The patches
>> and their reasonings are below.  I've also attached the patches for
>> the prototype credit2 scheduler, for reference.
>> 
>> * Add a context swich callback (sched-context_switch-callback.diff)
>> 
>> Add a callback to tell a scheduler that a vcpu has been completely
>> context-switched off a cpu.
>> 
>> When sharing a runqueue, we can't put a scheduled-out vcpu back on the
>> runqueue until it's been completely de-scheduled, because it may be
>> grabbed by another processor before it's ready.  This callback allows
>> a scheduler to detect when a vcpu on its way out is completely off the
>> processor, so that it can put the vcpu on the runqueue.
>> 
>> * Allow sharing of locks between cpus (sched-spin_lock-pointers.diff)
>> 
>> Have per-cpu pointers, initialized to per-cpu locks, which the
>> scheduler may change during its init to reconfigure locking
>> granularity.
>> 
>> There are a number of race conditions having to do with updating of
>> v->is_running and v->processor, all having to do with the fact that
>> vcpus may change cpus without an explicit migrate.  Furthermore, the
>> scheduler needs runqueues to be covered by a lock as well.  The
>> cleanest way to solve all of these is to have the scheduler lock and
>> the runqueue lock coincide.
>> 
>> * Add a "scheduler" trace class (trace-sched-class.diff)
>> Uses defined on a per-scheduler basis
>> 
>> I've been running parallel kernel compiles on a 16-way box (2x4x2) for
>> several hours now without deadlocks or BUG()s.  As far as I'm
>> concerned, with these changes, credit2 is now ready to be checked in,
>> as long as it's not set to the default scheduler.
>> 
>> All of the above:
>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>>