On Wed, 2025-01-15 at 20:14 -0500, Crystal Wood wrote: > On Tue, 2025-01-14 at 18:07 -0500, John Kacur wrote: > > > > On Tue, 14 Jan 2025, Crystal Wood wrote: > > > > > On Tue, 2025-01-14 at 07:40 +0100, Gabriele Monaco wrote: > > > > I could start drafting a patch for the CLI options to specify > > > > modules > > > > if they look alright to you. > > > > > > > > Another not too different option could be kinda like stress-ng, > > > > specifying the modules just like --cyclictest , --timerlat , -- > > > > hackbench , etc. > > > > > > It fits the pattern of module-specific parameters, so I kind of > > > like it > > > from an interface perspective. Implementation wise, though, > > > something > > > like > > > --load-modules='cyclictest,sysstat' or --load cyclictest --load > > > sysstat > > > might be easier (interface wise, I prefer the latter). > > > > > > > Note that cyclictest and timerlat in rteval jargon are measurement > > modules > > Sorry, brain fart... s/load/measurement/ (I'd prefer just "measure" > but > I guess we want to be consistent with stuff like --measurement- > cpulist) > > > The current way that load modules work is that most are implicitly > > implied. > > > > They're explicitly enabled in the default config file... > > > stress-ng is not among the default implicitly implied load > > modules, but if you choose stressng-option then it sets itself as > > an exclusive load module and turns off the others. If a person > > tries to > > run with a stressng-option and an option for an other load module, > > it is > > an error condition. > > > > It is possible to run both the cyclictest and timerlat measurement > > modules > > without using any specific cyclictest or timerlat options. (so that > > doesn't work as a way to differentiate) > > I don't think implicit enablement based on module-specific options is > a > good model to emulate, regardless. > > > > > There are some measurement module options that will apply to either > > one. > > For example > > --measurement-cpulist CPULIST > > > > will run measurement modules on the CPULIST whether that be > > cyclictest or > > timerlat. > > > > I think the simplest thing to do would be to implement these two > > options > > without parameters. > > --cyclictest > > --timerlat > > If you mean special casing these two modules rather than having a > general mechanism for enabling modules, I'm not a huge fan of that... > though it might be preferable to overengineering something. > > What about sysstat? > > And how would we specify a module to disable? If timerlat is the > default (currently this is only the case if the measurement section > of > the config file is missing), and the user enables cyclictest, do we > hardcode that that disables timerlat? Or have a way to prefer > command- > line-specified modules over conflicting default modules? > > > > > Now, you wouldn't HAVE to use them, currently timerlat is the > > default, so > > if you don't specify, then it would use the default. > > > > Like with stress-ng and the load modules, if a person tried to use > > a > > cyclictest and a timerlat option at the sametime, it should create > > an > > error and exit. > > > > I like the above idea, because other than the optional option of > > --cyclictest and --timerlat, nothing else changes, so it wouldn't > > break > > anybody's scripts in any kind of major way. > > None of these proposals should break existing scripts, assuming we > don't > change the defaults. Removing config file support, OTOH, would force > people still using cyclictest to start specifying it on the command > line > one way or another. Strictly speaking, enabling timerlat as the default measurement module did break existing scripts, that's what brought me to start this patch in the first place. I agree that we should try to keep the same behaviour with respect to default values, no measurement module specified via command line should be the same as no measurement section in the config files, as specifying only one should disable the other. Specifying both should be allowed. I see the command line as another setup that should override the config file, while behaving exactly the same (where the notation -- measurement-modules would indeed be a bit more familiar, but I still like --cyclictest/--timerlat). The order could be: command-line > explicit config file (-f) > default config file (/etc) > default values, this wouldn't affect the behaviour much. I only see the behaviour with stress-ng a bit strange, is it really not a thing to run it in conjunction with hackbench and kcompile? I see the simplest thing for now is to start with command-line options for measurement only. After we consolidate that, we can do the same for loads (with or without special cases). Thoughts? Gabriele
