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

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Fri, 2018-10-12 at 11:23 +0200, Juergen Gross wrote:
> On 12/10/2018 11:15, Dario Faggioli wrote:
> > 
> > But, anyway, if I'm in sched_dario.c, and schedule.c makes me
> > reason in
> > terms of vCores, how do I deal with single CPUs for a particular
> > cpupool that does not want core-scheduling?
> 
> sched_dario.c would only know of scheduling entities. Mapping of
> vcpus
> to scheduling entities is part of the infrastructure.
> 
> schedule.c would receive vcpu state changes. In case such a vcpu
> state change leads to a scheduling entity state change the related
> scheduler is informed about that to be able to react.
> 
> In case the scheduling entity is a thread (no core scheduling) each
> vcpu state change will result in a scheduling entity state change,
> so it will be as today.
> 
I think I'm starting to understand more your idea, although not
completely (or at least, I think I understand it completely, but I
still can't make up, in my mind, a fully complete picture of how the
code will look, and of how it will work).

I think I still see reasons why something like group-scheduling belongs
in sched_dario.c, rather than in schedule.c, but that may partly be
because I've been working on doing it in _that_way_ for some time, and
my brain is wrapped around such design. :-)

IAC, this really continues to look to me like a major rework of (not
only, probably) scheduling code. This, of course, does not mean this is
not worth doing, not per-se, at least. And although, as I said, I still
have some doubts, it is certainly possible that they'll be proven 
wrong by continuing the discussion, or by writing/seeing a prototype.

A little bit more on the practical side, there are patches out there
that let us achieve the goal, the Credit2 one being in the "not too
bad" state (at least IMO, and I'd be happy to have feedback on that).
In fact, with some effort, the Credit2 series could even be 4.12
material. I don't think the same would be true for the rework (and I'm
talking both in general, and considering my current situation, assuming
it would be me doing this --which is not necessarily the case, of
course :-D ).

So, basically, the way I personally see it more likely for us to get
core-scheduling not too far away in time, is by means of an approach
that does not require rewriting, and testing, and benchmarking (because
it's scheduling, look at what the process has been/is being to switch
to Credit2!) large portions of the scheduler.

And then maybe we can focus on how to make core-scheduling useful and
effective in really mitigating things like TLBLeed (via more topology
awareness in both guest and Xen) and L1TF (by the doing "panopticon"
[1] and/or truly synch'd context switches).

Others? Thoughts?

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

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