Re: [Xen-devel] [PATCH 54/60] xen/sched: add minimalistic idle scheduler for free cpus

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Tue, 2019-05-28 at 13:58 +0200, Juergen Gross wrote:
> On 28/05/2019 13:47, Jan Beulich wrote:
> > > > > On 28.05.19 at 12:33, <jgross@xxxxxxxx> wrote:
> > > Instead of having a full blown scheduler running for the free
> > > cpus
> > > add a very minimalistic scheduler for that purpose only ever
> > > scheduling
> > > the related idle vcpu. This has the big advantage of not needing
> > > any
> > > per-cpu, per-domain or per-scheduling unit data for free cpus and
> > > in
> > > turn simplifying moving cpus to and from cpupools a lot.
> > 
> > And the null scheduler is not minimalistic enough?
> 
> The main disadvantage of the null scheduler are the need for private
> data (which has to be allocated/freed on scheduler switch), its not
> yet perfect stability, and its "complexity" (e.g. 900 lines vs. 50).
> 
Yes, I absolutely agree with this approach of having an even simpler
idle scheduler, for the idle vcpus, and not selectable and usable by
the user for other things.

It would, actually, be rather useful in other ways and places, so I'm
actually rather happy to see it appearing (I started multiple times
doing something like this myself, but never finished :-/)

For instance, the fact that we put cpus that are not in any pool in the
default scheduler, was weird (to say the least) from a conceptual point
of view, forced us to do some extra checks (in the form of, e.g.,
cpumask() operations) to avoid actually scheduling vcpus on them and
was causing accounting issues in Credit1.

Now that the free cpus can go and stay in their own "idle scheduler",
those things can all be solved, in the (IMO) best and most clean way.

And, yes, it has to be as simple as possible, even simpler than null...
And I think we can easily see why that's the case, just by looking at
what code this patch let us remove (e.g., the need for some of the
checking of `system_state` in cpupool or scheduler code, just to
mention one).

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

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