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

[Dario Faggioli <dfaggioli@suse.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2826 bytes --]

On Fri, 2019-03-29 at 16:46 +0100, Juergen Gross wrote:
> On 29/03/2019 16:39, Jan Beulich wrote:
> > > > > On 29.03.19 at 16:08, <jgross@suse.com> wrote:
> > > 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.
> > 
> > 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?
> 
> In fact I'm doing it, but only implicitly and without adapting the
> cpuid related information. The idea is to pass the topology
> information
> at least below the scheduling granularity to the guest later.
> 
> Not having the fixed relationship would result in something like the
> co-scheduling series Dario already sent, which would need more than
> mechanical changes in each scheduler.
> 
Yep. So, just for the records, those series are, this one for Credit1:
https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02164.html

And this one for Credit2:
https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01113.html

Both are RFC, but the Credit2 one was much, much better (more complete,
more tested, more stable, achieving better fairness, etc).

In these series, the "relationship" being discussed here is not fixed.
Not right now, at least, but it can become so (I didn't do it as we
currently lack the info for doing that properly).

It is/was, IMO, a good thing that everything work both with or without
topology enlightenment (even for one we'll have it, in case one, for
whatever reason, doesn't care).

As said by Juergen, the two approaches (and hence the structure of the
series) are quite different. This series is more generic, acts on the
common scheduler code and logic. It's quite intrusive, as we can see
:-D, but enables the feature for all the schedulers all at once (well,
they all need changes, but mostly mechanical).

My series, OTOH, act on each scheduler specifically (and in fact there
is one for Credit and one for Credit2, and there would need to be one
for RTDS, if wanted, etc). They're much more self contained, but less
generic; and the changes necessary within each scheduler are specific
to the scheduler itself, and non-mechanical.

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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