On Thu, Jun 25, 2015 at 1:15 PM, Dario Faggioli <dario.faggi...@citrix.com> 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@lists.xen.org http://lists.xen.org/xen-devel
