Re: [Xen-devel] [PATCH v2] xen: sched: fix (ACPI S3) resume with cpupools with different schedulers.

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2015-11-24 at 15:32 +0000, George Dunlap wrote:
> On 13/11/15 17:10, Dario Faggioli wrote:
> >Â
> > During suspend, the pCPUs are not removed from their
> > pools with the standard procedure (which would involve
> > schedule_cpu_switch(). During resume, they:
> > Â1) are assigned to the default cpupool (CPU_UP_PREPARE
> > ÂÂÂÂphase);
> > Â2) are moved to the pool they were in before suspend,
> > ÂÂÂÂvia schedule_cpu_switch() (CPU_ONLINE phase)
> > 
> > During resume, scheduling (even if just the idle loop)
> > can happen right after the CPU_STARTING phase(before
> > CPU_ONLINE), i.e., before the pCPU is put back in its
> > pool.
> 
> So why are we restoring scheduling stuff during CPU_STARTING, but
> only
> putting cpus back in their pools at CPU_ONLINE?
> 
Indeed. Much worse: we open the CPU for scheduling before it's back in
its pool (this is all what this bug is about!). this never made much
sense to me.

> At some point I think I knew the answer to this, but it's worth
> revisiting it.
> 
So, I once had a look, and tried shuffling things around, in a way in
which the order made more sense to me, but it does not work 'out of the
box'.

The issues have, AFAICR, to do with the fact that memory allocations
(for the per-pCPU scheduling data, need IRQs enabled (which means
CPU_UP_PREPARE, much rather than CPU_STARTING, is what we want) on the
scheduling side, and other data that need to be ready and initialized
in order to setup cpupools (e.g., per_cpu(cpupool, cpu)).

As said, I don't recall all the details, sorry. I recall thinking that
a solution would involve putting the CPU in the pool earlier, but that
in turn calls for other work (e.g., tweaking the priorities of the
callbacks for avoiding races).

It's on my list of things to do, but not with super high priority. Are
you saying that we should drop this patch, and do the callback
reordering/refactoring first?

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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