On Tue, 14 Jan 2025, Crystal Wood wrote: > On Tue, 2025-01-14 at 07:40 +0100, Gabriele Monaco wrote: > > On Mon, 2025-01-13 at 16:34 -0500, John Kacur wrote: > > > > > > > > > On Mon, 13 Jan 2025, Gabriele Monaco wrote: > > > > > > > Modules can currently be set only via configuration file, if rteval > > > > is > > > > called from a script run on different systems, the only way to make > > > > sure > > > > the loaded modules are known is to provide (or generate) a > > > > configuration > > > > file and pass it via -f/--infile . > > > > > > The config files are almost obsolete. > > > Everything has a reasonable default, or can be set from the CMI > > > The one exception is for the measurement module. > > > > > > What would be useful would be a CMI interface to switch from rtla > > > timerlat > > > to cyclictest. > > > > > > > Mmh, that was actually my first idea, something like --measurement- > > modules=timerlat,cyclictest --loads-modules=hackbench > > Basically behaving just like the measurement and loads sections in the > > config. > > > > I opted for this as it was simpler but if the config file is getting > > obsolete, I think you can just ignore the patch. > > It's a simple enough patch that it might be worth taking anyway... > unless we actually do want to deprecate the config file entirely, rather > than just making sure it's not the only place where certain things can > be configured. I'm tending in the direction of deprecating the config file, I don't find it too useful. In any case, I don't want to add to it, we will then end up having to maintain that. > > > > > 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 The current way that load modules work is that most are implicitly implied. 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) 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 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. John > > > > Both would require a bit of refactoring how we load modules. > > That could be a good thing, if the new way is simpler. > > -Crystal > > >
