On Thu, 2025-01-16 at 07:45 +0100, Gabriele Monaco wrote: > > On Wed, 2025-01-15 at 20:14 -0500, Crystal Wood wrote: > > On Tue, 2025-01-14 at 18:07 -0500, John Kacur wrote: > > > 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. By "these proposals" I meant the command line stuff in this thread. > > 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. Why should specifying both be allowed? We go out of our way to prevent that, because they'll interfere with one another's latencies. > > 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. It's not the same, since the command line would only override individual options, while a config file replaces all defaults (at least when it comes to enabling modules, not sure about other defaults). > 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). What makes loads harder? -Crystal
