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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 25 Aug 2023 19:44:42 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     "Chatre, Reinette" <reinette.chatre@...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

> >> 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 mostly works. Except for the cases where different modules access
> > the same underlying hardware, so can't be loaded together.
> >
> > Examples:
> >
> > rdt_l3_cat vs. rdt_l3_cdp - user needs to decide whether they want CDP or not.
> > But this is already true ... they have to decide whether to pass the "-o cdp" option
> > to mount.
> >
> > rdt_l3_mba vs. rdt_l3_mba_MBps - does the user want to control memory bandwidth
> > with percentages, or with MB/sec values. Again the user already has to make this
> > decision when choosing mount options.
> >
> >
> > Maybe the "What resctrl options does this machine support?" question would be
> > best answered with a small utility?
>
> A user space utility or a kernel provided utility? If it is a user space utility
> I think it would end up needing to duplicate what the kernel is required to do
> to know if a particular feature is supported. It seems appropriate that this
> could be a kernel utility that can share this existing information with user
> space. resctrl already supports the interface for this via /sys/fs/resctrl/info.

I was imagining a user space utility. Even though /proc/cpuinfo doesn't show
all features, a utility has access to all the CPUID leaves that contain the
details of each feature enumeration.

> fyi ... as with previous attempts to discuss this work I find it difficult
> to discuss this work when you are selective about what you want to discuss/answer
> and just wipe the rest. Through this I understand that I am not your target
> audience.

Not my intent. I value your input highly. I'm maybe too avid a follower of the
"trim your replies" school of e-mail etiquette. I thought I'd covered the gist
of your message.

I'll try to be more thorough in responding in the future.

-Tony