From: Crystal Wood <crwood@redhat.com>
To: Gabriele Monaco <gmonaco@redhat.com>, John Kacur <jkacur@redhat.com>
Cc: Clark Williams <williams@redhat.com>,
Tomas Glozar <tglozar@redhat.com>,
linux-rt-users@vger.kernel.org
Subject: Re: [PATCH] rteval: Allow configuration from stdin
Date: Tue, 14 Jan 2025 14:50:56 -0500 [thread overview]
Message-ID: <8abfe0115fc4e7824f9d92743d9d41b5dbbdb50a.camel@redhat.com> (raw)
In-Reply-To: <7323d02c15095c659749147c3d2e9d4b777df2a2.camel@redhat.com>
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 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).
>
> Both would require a bit of refactoring how we load modules.
That could be a good thing, if the new way is simpler.
-Crystal
next prev parent reply other threads:[~2025-01-14 19:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-13 12:18 [PATCH] rteval: Allow configuration from stdin Gabriele Monaco
2025-01-13 12:30 ` Tomas Glozar
2025-01-13 21:34 ` John Kacur
2025-01-14 6:40 ` Gabriele Monaco
2025-01-14 19:50 ` Crystal Wood [this message]
2025-01-14 23:07 ` John Kacur
2025-01-16 1:14 ` Crystal Wood
2025-01-16 6:45 ` Gabriele Monaco
2025-01-16 20:56 ` Crystal Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8abfe0115fc4e7824f9d92743d9d41b5dbbdb50a.camel@redhat.com \
--to=crwood@redhat.com \
--cc=gmonaco@redhat.com \
--cc=jkacur@redhat.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=tglozar@redhat.com \
--cc=williams@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).