Re: [Xen-devel] [PATCH 00/12] add per-domain and per-cpupool generic parameters

[Dario Faggioli <dfaggioli@xxxxxxxx>]

[Hey, is it me/my mailer, or threading is weird for this series? :-O]

On Tue, 2018-09-18 at 14:57 +0100, George Dunlap wrote:
> On 09/18/2018 02:36 PM, Juergen Gross wrote:
> > 
> > The string variant is much more flexible.
> > 
> > It is easy possible to e.g. add a per-domain trace parameter to
> > specify
> > rather complex trace instrumentations. Doing something like that
> > via a
> > struct based interface is in the best case complicated.
> 
> ...or, for instance, specifying the runqueue layout of a cpupool (for
> schedulers like credit2 which allow such things).  Yes, that is true;
> but probably a very niche case.
> 
Exactly. As another example, I want to follow up on this:

https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg01644.html

More precisely, I want to add a per-cpupool "smt=[on|off|force]" (or
cpupool-smt, or something like that), with the following meaning:
- smt=on: cpus that are hyperthread siblings can be added to the 
  cpupool. Adding a cpu whose sibling is in another pool would fail;
- smt=off: only one cpu per core can be added to the cpupool. Adding a 
  cpu whose sibling is already in the pool would fail. Adding a cpu 
  whose sibling is in another pool would also fail;
- smt=force: (and I particularly dislike the name, but let's ignore it 
  for now) any cpu can be added to any pool

What I was putting together was something along the lines of:

https://lists.xenproject.org/archives/html/xen-devel/2017-09/msg01552.html

And then there will be the support for having a line like this, in a
cpupool config file:

 smt = "off"

With this approach, instead, there will have to be a line like this in
there:

 parameters = "smt=off"

Is that right?

And when we will also have the support for, say, per-cpupool runqueue
arrangement for Credit2, it will look like this:

 parameters = "credit2_runqueues=socket smt=off"

Right again?

If yes, I think I'm fine with this.

The per-cpupool parameters case is, I think, probably less
controversial than the per-domain case. In facte, the parsing of, e.g.,
credit2_runqueue=, happens in Xen already. And most (if not all) of the
scheduling parameters that we allow as command line options, also make
sense as per-cpupool parameters, so... :-)

I'm not sure where to draw the line, assuming we even want to draw one.
I.e., if we take this approach and these patches, _any_ new parameter
will have to be handled like this? If no, how do we decide which ones
better use the "hypervisor centric" string blobs, and which ones better
use the current "toolstack centric" one? About this (and especially for
per-domain params), I've much less clear ideas.

But as far as per-cpupools parameters are concerned, I do like this.

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

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