Re: [Xen-devel] [PATCH v3 00/47] xen: add core scheduling support

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Fri, 2019-09-20 at 18:14 +0200, Jan Beulich wrote:
> On 14.09.2019 10:52, Juergen Gross wrote:
> > This is achieved by switching the scheduler to no longer see vcpus
> > as
> > the primary object to schedule, but "schedule units". Each schedule
> > unit consists of as many vcpus as each core has threads on the
> > current
> > system. The vcpu->unit relation is fixed.
> 
> There's another aspect here that, while perhaps obvious, I didn't
> realize so far: Iirc right now schedulers try to place vCPU-s on
> different cores, as long as there aren't more runnable vCPU-s than
> there are cores. 
>
Indeed they do.

> This is to improve overall throughput, since
> vCPU-s on sibling hyperthreads would compete for execution
> resources. With a fixed relation this is going to be impossible.
>
It is. And that is the reason why my benchmarks show rather bad
performance for a 4 vCUPUs VMs on a 8 CPUs (4 cores, with
hyperthreading) host. In fact, as Juergen showed during his Xen Summit
talk, in such a case core-scheduling achieves much worse performance
than "regular" cpu-scheduling, both when hyperthreading is enabled and
disabled.

It's an intrinsic characteristic of this solution that we have decided
to go for (i.e., introducing the 'virtual core' and 'scheduling
resource' concepts, and act almost entirely at the schedule.c level).

> Otoh I can of course see how, once we have proper virtual
> topology, this allows better scheduling decisions inside the
> guest, in particular if - under the right circumstances - it is
> actually wanted to run two entities on sibling threads.
> 
Yes, this is indeed one aspect. There is also the fact that, currently,
as soon as you have 1 more vCPU than there are cores, e.g. coming from
another VM, the guest that had each of its vCPUs running on one core,
experiences a slowdown. While, with core-scheduling enabled from the
beginning, performance stays consistent.

In any case, this all happens with core-scheduling actually enabled.
With these patches applied, but cpu-scheduling selected at boot, fully
idle cores are still preferred, and the vCPUs will still be spread
among them (as soon as there's any available).

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel