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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.
> 
> All logical cpus (threads) of the core or socket are always scheduled
> together. This means that on a core always vcpus of the same domain
> will be active, and those vcpus will always be scheduled at the same
> time.
> 
> This is achieved by switching the scheduler to no longer see vcpus as
> the primary object to schedule, but "schedule items". Each schedule
> item consists of as many vcpus as each core has threads on the current
> system. The vcpu->item relation is fixed.

Hmm, I find this surprising: A typical guest would have more vCPU-s
than there are threads per core. So if two of them want to run, but
each is associated with a different core, you'd need two cores instead
of one to actually fulfill the request? I could see this necessarily being
the case if you arranged vCPU-s into virtual threads, cores, sockets,
and nodes, but at least from the patch titles it doesn't look as if you
did in this series. Are there other reasons to make this a fixed
relationship?

As a minor cosmetic request visible from this cover letter right away:
Could the command line option please become "sched-granularity="
or even "sched-gran="?

Jan



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