Re: [Xen-devel] [RFC PATCH v1 00/16] xen: sched: implement core-scheduling

[Juergen Gross <jgross@xxxxxxxx>]

On 25/08/18 01:35, Dario Faggioli wrote:
> Hello,
> 
> As anticipated here:
> https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02052.html
> 
> Here's a preliminary version of my work, trying to implement
> core-scheduling in Xen.
> 
> First of all, this deals with Credit1 only. I have patches for Credit2,
> and I've been working on having them ready by today, but I could not
> defeat the latest bugs. :-/
> I'll post them when back from vacation. Just let me anticipate, that
> doing something like this in Credit2, is a lot simpler than what you
> see here for Credit1.
> 
> Even these patches that I'm posting are not perfect, and In fact there
> are some TODOs and XXXs --both in the changelogs and in the code.
> 
> They give me a system that boots, where I can do basic stuff (like
> playing with dom0, creating guests, etc), and where the constraint of
> only scheduling vcpus from one domain at a time on pcpus that are part
> of the same core is, as far as I've seen, respected.
> 
> There are still cases where the behavior is unideal, e.g., we could
> make a better use of some of the cores which are, some of the times,
> left idle.
> 
> There are git branches here:
>  https://gitlab.com/dfaggioli/xen.git rel/sched/core-scheduling-RFCv1
>  https://github.com/fdario/xen.git rel/sched/core-scheduling-RFCv1
> 
> Any comment is more than welcome.

Have you thought about a more generic approach?

Instead of trying to schedule only vcpus of the same domain on a core
I'd rather switch form vcpu scheduling to real core scheduling. The
scheduler would see guest cores to be scheduled on physical cores. A
guest core consists of "guest threads" being vcpus (vcpus are bound
to their guest cores, so that part of the topology could even be used
by the guest for performance tuning). The state of a guest core
(running, runnable, blocked) is defined by the combination of all of its
vcpus (at least one vcpu running -> core running, all vcpus blocked ->
core blocked, all runnable -> core runnable). This means we would need
to introduce the new vcpu state "idle" (in case the other vcpu of the
core is running).

The state machine determining the core state from its vcpus would be
scheduler agnostic (schedule.c), same for switching guest cores on a
physical core.

This scheme could even be expanded for socket scheduling.


Juergen

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