From: Reinette Chatre <reinette.chatre@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>,
Amit Singh Tomar <amitsinght@marvell.com>,
"Yu, Fenghua" <fenghua.yu@intel.com>,
"james.morse@arm.com" <james.morse@arm.com>,
George Cherian <gcherian@marvell.com>,
"robh@kernel.org" <robh@kernel.org>,
"peternewman@google.com" <peternewman@google.com>,
Drew Fustini <dfustini@baylibre.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: resctrl2 - status
Date: Fri, 25 Aug 2023 10:47:12 -0700 [thread overview]
Message-ID: <35f05064-a412-ad29-5352-277fb147bbc4@intel.com> (raw)
In-Reply-To: <DS7PR11MB6077FE180B11A9138D8E7ED7FC1DA@DS7PR11MB6077.namprd11.prod.outlook.com>
Hi Tony,
On 8/24/2023 11:10 AM, Luck, Tony wrote:
..
> After booting load the modules you want for the features you want
> before (or after) mounting /sys/fs/resctrl.
Could you please elaborate how user space is expected to
operate? For example, focusing on "load the modules you want",
sounds like user space is required to know what feature is supported
by the underlying hardware and load appropriate module in response.
In current resctrl the agreement is that the features are no longer
visible in /proc/cpuinfo if their support can be discovered via resctrl.
See, for example, how SMBA and BMEC does not appear in /proc/cpuinfo
because user space can learn about them via content in
/sys/fs/resctrl/info.
User space thus cannot rely on parsing /proc/cpuinfo to know which
modules to load. resctrl also supports module specific features,
like pseudo-locking making feature detection more complicated.
I'd expect that in the near future there will be a variety of ways
(beyond just running CPUID) in which features should be enumerated.
Is the expectation that user space needs to know how to enumerate
all the various features to know which modules can/should be loaded?
Alternatively, can user space just take a "load all resctrl modules
and see what sticks" (even modules of different architectures since
a user space may want to be generic) approach?
This work is stated to "make it easier for CPU architectures
with different underlying resource control and monitoring capabilities to
implement those features without being unduly constrained by the quirks
of other architectural designs". It is not clear to me why making
the code modular requires everything to be modules.
Finally, what is the plan to deal with current users that just mount
resctrl and expect to learn from it what features are supported?
>
> There are no mount options. Just pick the right modules. E.g.
>
> # modprobe rdt_l3_cat
>
> for basic L3 cache control
>
> # modprobe rdt_l3_cdp
>
> for L3 cache control with code/data prioritization
>
> # modprobe rdt_l3_pseudolock
>
> for L3 cache control with pseudo cache locking support
Reinette
next prev parent reply other threads:[~2023-08-25 17:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 18:10 Luck, Tony
2023-08-25 17:47 ` Reinette Chatre [this message]
2023-08-25 18:09 ` Luck, Tony
2023-08-25 18:58 ` Reinette Chatre
2023-08-25 19:44 ` Luck, Tony
2023-08-25 20:20 ` Reinette Chatre
2023-08-25 20:54 ` Tony Luck
2023-08-25 23:08 ` Reinette Chatre
2023-08-26 1:11 ` Tony Luck
2023-08-28 14:50 ` Reinette Chatre
2023-09-06 18:21 ` Tony Luck
2023-09-08 18:08 ` Moger, Babu
2023-09-08 18:51 ` Luck, Tony
2023-09-08 21:35 ` Moger, Babu
2023-09-08 23:13 ` Tony Luck
2023-09-15 17:55 ` Drew Fustini
2023-09-18 10:44 ` Jonathan Cameron
2023-09-28 8:47 ` Peter Newman
2023-09-28 14:47 ` Luck, Tony
2023-09-29 9:38 ` Jonathan Cameron
2023-09-29 14:49 ` Drew Fustini
2023-09-15 17:16 ` James Morse
2023-09-15 20:38 ` Tony Luck
2023-09-21 0:21 ` Tony Luck
2023-09-19 12:53 ` Peter Newman
2023-09-19 16:40 ` Tony Luck
2023-08-29 10:23 ` Jonathan Cameron
2023-08-29 17:18 ` [EXT] " Amit Singh Tomar
2023-08-30 10:47 ` Jonathan Cameron
2023-09-15 17:16 ` James Morse
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=35f05064-a412-ad29-5352-277fb147bbc4@intel.com \
--to=reinette.chatre@intel.com \
--cc=amitsinght@marvell.com \
--cc=dfustini@baylibre.com \
--cc=fenghua.yu@intel.com \
--cc=gcherian@marvell.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peternewman@google.com \
--cc=robh@kernel.org \
--cc=tony.luck@intel.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
all inboxes | Powered by JetHome®