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

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Fri, 2018-10-12 at 19:43 +0200, Dario Faggioli wrote:
> 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.
> 
So... Any idea? Thoughts? First impressions? :-D

Thanks and 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