Re: [Xen-devel] [PATCH 4/9] xen: sched: add .init_pdata hook to the scheduler interface

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.09.15 at 18:55, <dario.faggioli@xxxxxxxxxx> wrote:
> This happens because, right now, the scheduler of the
> target pool remaps the runqueue lock during (rt_)alloc_pdata,
> which is called at the very beginning of schedule_cpu_switch().
> Credit2's csched2_free_pdata(), however, wants to find the spin
> lock the same way it was put by csched2_alloc_pdata(), and
> explodes, it not being the case.
> 
> This patch also fixes this as, now, spin lock remapping
> happens in the init_pdata hook of the target scheduler for
> the pCPU, which we can easily make sure it is ivoked *after*
> the free_pdata hook of the old scheduler (which is exactly
> what is done in this patch), without needing to restructure
> schedule_cpu_switch().

Hmm, while I can see this to be okay for the
cpupool_unassign_cpu_helper() case (due to the call to
cpu_disable_scheduler() up front) as well as for the
cpupool_cpu_add() one (I take it that the CPU can't be
scheduled on in that case), I don't see how this would be
safe for the XEN_SYSCTL_CPUPOOL_OP_ADDCPU case: How is
scheduling activity being prevented to happen after the new
ppriv got installed, but before it gets initialized via the init_pdata
hook? Or how would scheduling activity be safe with an allocated
but not yet initialized ppriv?

Jan


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