Re: [Xen-devel] [PATCH 3/4] xen: credit1: properly deal with pCPUs not in any cpupool

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, Jun 25, 2015 at 1:15 PM, Dario Faggioli
<dario.faggioli@xxxxxxxxxx> wrote:
> Ideally, the pCPUs that are 'free', i.e., not assigned
> to any cpupool, should not be considred by the scheduler
> for load balancing or anything. In Credit1, we fail at
> this, because of how we use cpupool_scheduler_cpumask().
> In fact, for a free pCPU, cpupool_scheduler_cpumask()
> returns a pointer to cpupool_free_cpus, and hence, near
> the top of csched_load_balance():
>
>  if ( unlikely(!cpumask_test_cpu(cpu, online)) )
>      goto out;
>
> is false (the pCPU _is_ free!), and we therefore do not
> jump to the end right away, as we should. This, causes
> the following splat when resuming from ACPI S3 with
> pCPUs not assigned to any pool:

What I haven't quite twigged yet with regard to this specific bug is
why csched_load_balance() is being run on this cpu at all if it hasn't
been added to the cpupool yet.  AFAICT it's only called from
csched_schedule() -- why is that being called on a cpu that isn't
online yet?  If we can't fix that before the code freeze (or if we
wouldn't want to avoid it anyway), would it make more sense to check
for that condition in csched_schedule() and just return the idle
domain?

(Or schedule() even?)

 -George

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