]> xenbits.xensource.com Git - xen.git/commit
SEDF: avoid gathering vCPU-s on pCPU0
authorJan Beulich <jbeulich@suse.com>
Mon, 4 Mar 2013 09:17:52 +0000 (10:17 +0100)
committerJan Beulich <jbeulich@suse.com>
Mon, 4 Mar 2013 09:17:52 +0000 (10:17 +0100)
commite6a6fd63652814e5c36a0016c082032f798ced1f
tree9bec7408703235d88385108b44d897b450786055
parent7ffc9779aa5120c5098d938cb88f69a1dda9a0fe
SEDF: avoid gathering vCPU-s on pCPU0

The introduction of vcpu_force_reschedule() in 14320:215b799fa181 was
incompatible with the SEDF scheduler: Any vCPU using
VCPUOP_stop_periodic_timer (e.g. any vCPU of half way modern PV Linux
guests) ends up on pCPU0 after that call. Obviously, running all PV
guests' (and namely Dom0's) vCPU-s on pCPU0 causes problems for those
guests rather sooner than later.

So the main thing that was clearly wrong (and bogus from the beginning)
was the use of cpumask_first() in sedf_pick_cpu(). It is being replaced
by a construct that prefers to put back the vCPU on the pCPU that it
got launched on.

However, there's one more glitch: When reducing the affinity of a vCPU
temporarily, and then widening it again to a set that includes the pCPU
that the vCPU was last running on, the generic scheduler code would not
force a migration of that vCPU, and hence it would forever stay on the
pCPU it last ran on. Since that can again create a load imbalance, the
SEDF scheduler wants a migration to happen regardless of it being
apparently unnecessary.

Of course, an alternative to checking for SEDF explicitly in
vcpu_set_affinity() would be to introduce a flags field in struct
scheduler, and have SEDF set a "always-migrate-on-affinity-change"
flag.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen/common/sched_sedf.c
xen/common/schedule.c