[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 01.04.19 at 08:49, <jgross@xxxxxxxx> wrote:
> On 01/04/2019 08:41, Jan Beulich wrote:
>>>>> On 29.03.19 at 16:08, <jgross@xxxxxxxx> wrote:
>>> Via boot parameter sched_granularity=core (or sched_granularity=socket)
>>> it is possible to change the scheduling granularity from thread (the
>>> default) to either whole cores or even sockets.
>> 
>> 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.
> 
>> 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".

"cpu" is fine of course. I wonder though whether the other two
were a good choice for "credit2_runqueue". Stefano, Julien -
is this terminology at least half way suitable for Arm?

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.