[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 2/2] sched_credit2.c: runqueue_per_core code
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |