[Xen-devel] [RFC PATCH v1 0/8] Series short description

[Dario Faggioli <dfaggioli@xxxxxxxx>]

Hello,

Here it comes, core-scheduling for Credit2 as well. Well, this time,
it's actually group-scheduling (see below).

 git://xenbits.xen.org/people/dariof/xen.git 
rel/sched/credit2/group-scheduling-RFCv1
 
http://xenbits.xen.org/gitweb/?p=people/dariof/xen.git;a=shortlog;h=refs/heads/rel/sched/credit2/group-scheduling-RFCv1

 (Or 
https://github.com/fdario/xen/tree/rel/sched/credit2/group-scheduling-RFCv1 ,
  Or 
https://gitlab.com/dfaggioli/xen/tree/rel/sched/credit2/group-scheduling-RFCv1 )

An RFC series implementing the same feature for Credit1 is here:
https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02164.html

The two series, however, are completely independent, and I'd recommend
focusing on this one first. In fact, implementing the feature here in
Credit2 was waaay simpler, and the result is, IMO, already a lot better.

Therefore, I expect that the amount of effort required for making this
very series upstreamable to be much smaller than for the Credit1 one.
When this is in, we'll have one scheduler that supports
group-scheduling, and we can focus on what to do with the others.

Let me also point out, that there is some discussion (in the thread of
the Credit1 RFC series [1]), about whether a different approach toward
implementing core/group-scheduling wouldn't be better. I had this code
almost ready already, and so I decided to send it out anyway. If it then
turns out that we have to throw it away, then fine. But, so far, I'm all
but convinced that the way things are done in this series is not our
current best solution to deal with the problems we have at hand.

So, what's in here? Well, we have a generic group scheduling
implementation which seems to me to work reasonably well... For an
RFC. ;-P

I call it generic because, although the main aim is core-scheduling, it
can be made to work (and in fact, it already kind of does) with
different grouping (like node, socket, or arbitrary sets of CPUs).

I does not have the fairness and starvation issues that the RFC series
for Credit1 liked above has. I.e., it already sort-of works. :-D

Some improvements are necessary, mostly because Credit2 is not a fully
work conserving scheduler, and this hurts when we do things like group
scheduling. So we need to add logic for doing some quick load-balancing,
or work stealing, when a CPU goes idle, but that is not that much of a
big deal (I was already thinking to add it anyway).

Finding a way of considering group-scheduling while doing proper load
balancing is also on my todo list. It is less easy than the work
conserving-ification described above, but also less important, IMO.

What's not there? Well, mainly, we're missing updating the docs, and
tracing. About the latter, I have an unfinished patch which adds
tracepoints that will be useful to observe, understand and debug whether
the code behave as we expect. And I'll send out that soon too.

Some notes on the actual patches:
- patches 1 and 2 have been submitted already, but they're necessary
  for testing this series, so I've included them;
- credit2_group_sched=core has been not only boot tested, but I've also
  thrown at him a couple of (basic) workloads.
  credit2_group_sched=no has been also tested not to break things (but,
  e.g., I haven't measured the overhead the series introduces).
  credit2_group_sched=node has been boot tested, but not much else;
- cpupool and CPU hotplug have _not_ been tested;

Thanks and Regards,
Dario

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-09/msg00707.html
    https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01010.html

PS. I'm Cc-ing a few people with which we've discussed these issues, but
    only to this cover letter, to avoid spamming you with scheduling code.
    Find the patches on the list/git, or ping me, and I'll mail them to
    you... :-)
---
Dario Faggioli (8):
      xen: sched: Credit2: during scheduling, update the idle mask before using 
it
      xen: sched: Credit2: avoid looping too much (over runqueues) during load 
balancing
      xen: sched: Credit2: show runqueue id during runqueue dump
      xen: sched: Credit2: generalize topology related bootparam handling
      xen: sched: Credit2 group-scheduling: data structures
      xen: sched: Credit2 group-scheduling: selecting next vcpu to run
      xen: sched: Credit2 group-scheduling: tickling
      xen: sched: Credit2 group-scheduling: anti-starvation measures


 xen/common/sched_credit2.c |  492 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 439 insertions(+), 53 deletions(-)
--
<<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/

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