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

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

On 03/19/2015 12:29 PM, Dario Faggioli wrote:
> On Thu, 2015-03-19 at 11:40 +0000, George Dunlap wrote:
>> On 03/19/2015 10:50 AM, Jan Beulich wrote:
>>>>>> On 19.03.15 at 11:03, <dario.faggioli@citrix.com> wrote:
> 
>>>> 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.
>>
> Right.
> 
>> /me pokes around and thinks some more...
>>
> So, if I can ask, how about my idea of splitting alloc_ and init_ parts
> of pCPU initialization ? :-)

Architecturally, from some points of view it makes sense -- actually
having "alloc_pdata" mean "initialize the cpu" is a bit weird; from
other points of view, it would be nicer not to multiply callbacks and
make the interface more complicated.

But from a practical point of view, this path is already more work than
I was expecting it to be, so I don't think we should spend *too* much
time looking for alternatives.  If that seems like the best option at
the moment, then I'm fine with it.

 -George