[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB6083C0ED50E9B644F4AF8E4BFCE3A@SJ1PR11MB6083.namprd11.prod.outlook.com>
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
Powered by blists - more mailing lists