Re: [Xen-devel] [PATCH v3 40/47] xen/sched: prepare per-cpupool scheduling granularity

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Tue, 2019-09-24 at 15:34 +0200, Jan Beulich wrote:
> On 14.09.2019 10:52, Juergen Gross wrote:
> > --- a/xen/include/xen/sched-if.h
> > +++ b/xen/include/xen/sched-if.h
> > @@ -25,6 +25,15 @@ extern int sched_ratelimit_us;
> >  /* Scheduling resource mask. */
> >  extern const cpumask_t *sched_res_mask;
> >  
> > +/* Number of vcpus per struct sched_unit. */
> > +enum sched_gran {
> > +    SCHED_GRAN_cpu,
> > +    SCHED_GRAN_core,
> > +    SCHED_GRAN_socket
> > +};
> 
> Seeing the almost absurd arrangement on my AMD Fam17 system (128 CPUs
> per Credit2 runqueue, for a total of two runqueues) I really wonder
> whether there shouldn't be a plan for a further intermediate
> granularity between "core" and "socket". The other day I did notice
> Linux has gained the concept of "die", which would bring the
> arrangement to a more reasonable 8 runqueues of 32 CPUs each on this
> system. (I'm taking Credit2 as a reference here only.)
> 
The default Credit2 setup on such system does indeed make no sense.

Introducing DIE (or whatever we want to call it) granularity for
Credit2 runqueues, and, in general, doing something more clever when
deciding how many CPUs should end up in the same runqueue is definitely
something we want.

Actually, there are patches already for specifying, at boot time, a
totally arbitrary runqueue arrangement.... I just need to fish them
from the list, rebase and resubmit. This does not cover the case above,
as we will still need a more sensible default, but it goes in the right
direction, I think.

That's, however, something which although quite important for Credit2,
is less of a concern for core-scheduling. In fact, as said elsewhere
already, I really don't expect anyone to want to use either die-
scheduling, socket-scheduling or anything different than core-
scheduling anytime soon.

I'll look into the Credit2 runqueue issue (for 4.14).

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