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

[Juergen Gross <jgross@suse.com>]

On 26/09/18 17:10, Dario Faggioli wrote:
> [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?

Right now, yes :-)

I could imagine to modify config file parsing to treat all unknown
key-value pairs as parameters, so you could use "smt=off" again. This
would have the effect to filter out all unsupported lines in the config
file.

> 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.

All parameters _needed_ at cpupool creation time (e.g. scheduler) can't
be handled this way. And I don't think it is a good idea to handle cpu
assignments that way.

> 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.

Thanks.


Juergen


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