Re: [Xen-devel] [PATCH RFC 00/49] xen: add core scheduling support

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Mon, 2019-04-01 at 08:49 +0200, Juergen Gross wrote:
> On 01/04/2019 08:41, Jan Beulich wrote:
> > One further general question came to mind: How about also having
> > "sched-granularity=thread" (or "...=none") to retain current
> > behavior, at least to have an easy way to compare effects if
> > wanted? But perhaps also to allow to deal with potential resources
> > wasting configurations like having mostly VMs with e.g. an odd
> > number of vCPU-s.
> 
> Fine with me.
> 
Mmm... I'm still in the process of looking at the patches, so there
might be something I'm missing, but, from the descriptions and from
talking to you (Juergen), I was assuming that to be the case already...
isn't it so?

> > The other question of course is whether the terms thread, core,
> > and socket are generic enough to be used in architecture
> > independent code. Even on x86 it already leaves out / unclear
> > where / how e.g. AMD's compute units would be classified. I
> > don't have any good suggestion for abstraction, so possibly
> > the terms used may want to become arch-specific.
> 
> I followed the already known terms from the credit2_runqueue
> parameter. I think they should match. Which would call for
> "sched-granularity=cpu" instead of "thread".
> 
Yep, I'd go for cpu. Both for, as you said, consistency and also
because I can envision "granularity=thread" being mistaken/interpreted
as a form of "thread aware co-scheduling" (i.e., what
"granularity=core" actually does! :-O)

Regards,
Dario
-- 
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