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

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1377 bytes --]

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 ? :-)

Regards,
Dario

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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