Re: [Xen-devel] [PATCH v2 2/2] sched_credit2.c: runqueue_per_core code

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 03/19/2015 10:50 AM, Jan Beulich wrote:
>>>> On 19.03.15 at 11:03, <dario.faggioli@xxxxxxxxxx> wrote:
>> OTOH, CPU_STARTING callbacks run:
>>  - on the cpu being brought up;
>>  - with interrupt disabled (see how the call to local_irq_enable(), in
>>    start_secondary(), is *after* the invocation of
>>    notify_cpu_starting()).
>>
>> Here we are. And the reason why things works ok in Credit2, is that
>> csched2_alloc_pdata() doesn't really allocate anything! In fact, in
>> general, handling alloc_pdata() during CPU_STARTING would mean that we
>> can't allocate any memory which, given the name of the function, would
>> look rather odd. :-)
>>
>> Nevertheless I see the value of doing so, and hence I think what we
>> could do would be to introduce a new hook in the scheduler interface,
>> called .init_pdata or .init_pcpu, and, in sched_*.c, split the
>> allocation and the initialization parts. The former will be handled
>> during CPU_UP_PREPARE, when allocation is possible, the latter during
>> CPU_STARTING, when we have more info available to perform actual
>> initializations.
> 
> Another alternative would be a new CPU_ALIVE (name subject to
> change) notification after interrupts got enabled. That would (as
> a follow-up cleanup) also allow the MTRR and microcode setup on
> the CPU to no longer need explicit calls (which look reversed
> anyway - surely we should update microcode before fiddling with
> MTRRs).

local_irq_enable() happens after setting the cpu as online in
cpu_online_map; not having the scheduler ready to actually schedule on
it at that time seems like it's asking for trouble.

/me pokes around and thinks some more...

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel