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
