[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB6083BC6B330FA7B7DFD3E76AFCE3A@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Fri, 25 Aug 2023 18:09:44 +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?
-Tony
Powered by blists - more mailing lists