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