[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH v1 00/16] xen: sched: implement core-scheduling
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |