linux-kernel - Re: resctrl2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 25 Aug 2023 10:47:12 -0700
From:   Reinette Chatre <reinette.chatre@...el.com>
To:     "Luck, Tony" <tony.luck@...el.com>,
        Amit Singh Tomar <amitsinght@...vell.com>,
        "Yu, Fenghua" <fenghua.yu@...el.com>,
        "james.morse@....com" <james.morse@....com>,
        George Cherian <gcherian@...vell.com>,
        "robh@...nel.org" <robh@...nel.org>,
        "peternewman@...gle.com" <peternewman@...gle.com>,
        Drew Fustini <dfustini@...libre.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: resctrl2 - status

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