Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept
From: Reinette Chatre
Date: Thu Jul 23 2026 - 19:31:54 EST
Hi Fenghua,
On 7/23/26 3:27 PM, Fenghua Yu wrote:
> On 7/23/26 09:18, Reinette Chatre wrote:
>> On 7/22/26 5:17 PM, Fenghua Yu wrote:
>>> On 7/14/26 15:06, Reinette Chatre wrote:
>>>> On 7/10/26 1:59 PM, Fenghua Yu wrote:
>>>>> On 6/25/26 08:43, Reinette Chatre wrote:
>>>>>> On 6/24/26 6:26 PM, Fenghua Yu wrote:
>>>>>>> On 6/24/26 15:22, Reinette Chatre wrote:
>>>>>>>> On 6/24/26 12:08 PM, Fenghua Yu wrote:
>>>>>>>>> On 5/29/26 11:06, Reinette Chatre wrote:
>>
>> ...
>>
>>>>>>>>> 2. /sys/fs/resctrl/info/MB/max_lim
>>>>>>>>> It shows number 0-3 for MPAM MBW max limit behaviors: 0 for supporting both softlimit and hardlimit, etc.
>>>>>>>>
>>>>>>>> Again this adds another *global* property to the MB resource but then above you
>>>>>>>> describe the new "MB_HLIM" schemata file entry that implies that it is a new control
>>>>>>>> for the MB resource. Having it be a new control for the MB resource matches earlier
>>>>>>>> discussions. To support this I thus expect it to be exposed as a new control with
>>>>>>>> potentially a new type if any of the existing planned types do not suffice.
>>>>>>>>
>>>>>>>
>>>>>>> How about adding these MB_HLIM dir and files in info?
>>>>>>>
>>>>>>> /sys/fs/resctrl/info/MB_HLIM/resource_schemata/MB_HLIM/type: boolean
>>>>>>> /sys/fs/resctrl/info/MB_HLIM/resource_schemata/MB_HLIM/max_lim: 0
>>>>>>
>>>>>> This presents "MB_HLIM" as a *resource* to user space. It is not a resource
>>>>>> but a *control* of a resource, no? I thus expect it to instead look something like
>>>>>> below that makes it clear that MB_HARDMAX is a control of the MB resource.
>>>>>>
>>>>>> info
>>>>>> └── MB
>>>>>> └── resource_schemata
>>>>>> ├── MB
>>>>>> └── MB_HARDMAX
>>>>>
>>>>> Yes, this makes sense. I have changed to this hierarchy.
>>>>
>>>> Thank you very much for considering this approach.
>>>
>>> [ MB_MAXHLIM: I use this name for MBW_MAX hard limit feature as Dave Martin suggested before. He also suggested MB_HARDMAX. Either name is good for me. I use MB_MAXHLIM to explain MBW_MAX hard limit for now.]
>>>
>>> Some implementation thoughts:
>>>
>>> MBW_MAX hard limit itself is not a MB control. Rather, it configures
>>> MB control, i.e. turn on MB control's hard limit or turn off its
>>> hard limit. So MBW_MAX hard limit doesn't have properties like
>>> bandwidth_gran, delay_linear, etc. MBW_MAX hard limit's property is
>>> only a boolean type.
>>
>> "MB" is becoming more and more a software concept that represents memory
>> bandwidth allocation and in that sense I agree that the "hard limit" is not
>> a "MB" control. Even so, since "hard limit" needs to be exposed via
>> schemata file it is *a* control. This is because as part of exposing it via
>> the schemata file it requires the following:
>> - a "scope" that specifies what the "domain ID" associated with this control in schemata file means
>> - "domains" to be the list of domains, one per "domain ID" from "scope", to contain the
>> staged values that user space provides when making changes to this control
>> - a "name" that is presented in schemata file
>> - resctrl needs a way to pass the user provided values to the architecture for
>> programming, the API for this is to pass struct resctrl_ctrl.
>>
>> You are correct that none of the current control types are a good fit for this
>> new boolean type. resctrl would need to support a new boolean control type.
>> Ben and I recently exchanged a few ideas around this. Please see the thread
>> that starts with the message below (search for HARDLIM in the message):
>> https://lore.kernel.org/lkml/34b95afb-8b60-4680-9ad1-90c5b24e8fb7@xxxxxxx/
>
> Yes, I had some input in the thread.
>
>>
>>
>>>
>>> So I would think it maybe a configuration inside a control.
>>>
>>> Similar configurations could be hard limit for cache capacity in MPAM.
>>>
>>> Maybe can add "configs" inside resctrl_ctrl. Schemata and info/MB/
>>> resource_schemata/MB will show/write the configurations per control?
>>>
>>> For this configuration or future configurations, add "configs" list in:
>>> struct resctrl_ctrl {
>>> struct list_head entry;
>>> enum resctrl_scope scope;
>>> struct list_head domains;
>>> enum resctrl_ctrl_type type;
>>> enum resctrl_ctrl_name name;
>>> struct resctrl_ctrl *emulated_by;
>>> struct list_head configs; <--- Add configs for this control
>>> union {
>>> struct resctrl_cache cache;
>>> struct resctrl_membw membw;
>>> };
>>> };
>>
>> As I understand the idea is that configs is a list of struct resctrl_ctrl?
>
> Yes, it's a list. A control may have a few configurations. Currently
> there is only MB_MAXHLIM configuration in the list in MB control. A
> list may be expanded to future multiple configurations in one
> control.
My question was actually what the list members would look like. This is not
clear from your proposal. I expect them to, in turn, be another list of
struct resctrl_ctrl. This list thus introduces an additional layer of
abstraction that I do not currently see the need for.
>> At first glance it is not clear to me why the additional layer of abstraction is
>> needed. What do you think of Ben's suggestion in thread I mentioned earlier to
>> instead name the control:
>> "<resource_type>_<scope>_<control>_<control_param> where <control_param> is HARDLIM"
>> (nit: While I understand HARDLIM matches more closely to MPAM spec I do find
>> "HARDMAX" easier to understand)
>
> Yes, add the name HARDLIM is fine too.
>
> But the arguments for adding this configurations in a control are:
>
> A "configurations" is different from a "control" in that:
> 1. The configuration configures the control, e.g. toggle hard limit on
> MB control.
I think it can be argued that "hard limit" is a control since a "control"
is something exposed to user via schemata file that is used by user space
to control how a resource is allocated.
> 2. The configuration doesn't have the control's properties (e.g. gran).
This is because "hard limit" is not a control of scalar type. "hard limit" is
a boolean control that still needs to be introduced to resctrl. I am in process of
refining the PoC based on feedback so far and adjusted the struct resctrl_ctrl
naming that I hope will make this clear.
struct resctrl_ctrl needs to be changed to support "hard limit".
Currently struct resctrl_ctrl looks like:
struct resctrl_ctrl {
struct list_head entry;
enum resctrl_scope scope;
struct list_head domains;
enum resctrl_ctrl_type type;
enum resctrl_ctrl_name name;
union {
struct resctrl_ctrl_bitmap bitmap;
struct resctrl_ctrl_scalar scalar;
};
};
To support "hard limit" resctrl needs changes like:
diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
index 6ca7474680b7..6eb7ce831830 100644
--- a/include/linux/resctrl.h
+++ b/include/linux/resctrl.h
@@ -323,6 +323,10 @@ struct resctrl_ctrl_scalar {
u32 reset_val;
};
+struct resctrl_ctrl_boolean {
+ /* to be completed */
+};
+
enum resctrl_scope {
RESCTRL_L2_CACHE = 2,
RESCTRL_L3_CACHE = 3,
@@ -334,6 +338,7 @@ enum resctrl_scope {
* enum resctrl_ctrl_type - The control type
* @RESCTRL_CTRL_BITMAP: The control is a bitmap in hex.
* @RESCTRL_CTRL_SCALAR: The control is a decimal number.
+ * @RESCTRL_CTRL_BOOLEAN: The control is a boolean.
*
* Used in struct resctrl_ctrl to identify the member struct that contains the
* properties of the control.
@@ -345,6 +350,7 @@ enum resctrl_scope {
enum resctrl_ctrl_type {
RESCTRL_CTRL_BITMAP,
RESCTRL_CTRL_SCALAR,
+ RESCTRL_CTRL_BOOLEAN,
};
/**
@@ -400,6 +406,7 @@ enum resctrl_ctrl_name {
* @bitmap: Bitmap control properties. Used by cache allocation.
* @scalar: Scalar control properties. Valid when @type == RESCTRL_CTRL_SCALAR.
* Used by memory bandwidth allocation.
+ * @boolean: Boolean control properties. Valid when @type == RESCTRL_CTRL_BOOLEAN.
*/
struct resctrl_ctrl {
struct list_head entry;
@@ -410,6 +417,7 @@ struct resctrl_ctrl {
union {
struct resctrl_ctrl_bitmap bitmap;
struct resctrl_ctrl_scalar scalar;
+ struct resctrl_ctrl_boolean boolean;
};
};
> 3. The configuration is similar to "event_configs" in MB_MON, that can
> also configure MB_MON's event_filter.
I am not able to see this connection.
event configurations enable global configuration of how monitoring events behave
(what they monitor). Attempting to map this to controls looks to me as mapping them
to the foundation of the new schema descriptions where control properties could theoretically
(not supported today) be writable and not as today just read-only. Mapping to event
configurations would have the "configuration" changes to control impact all resource
groups.
> So distinguish "configuration" and "control" might be more hierarchy? Adding the config name in control name doesn't show the hierarchy of the MB and its configs?
The hierarchy is indeed shown in the control name when the control name is
<resource_type>_<scope>_<control>_<control_param>, no?
>> The additional layer of abstraction would require both resctrl fs and
>> the architecture to dig through two lists when handling these controls and it is
>> not clear to me that this is necessary.
>>
>>
>>> A resctrl control can have one or multiple configurations. Currently
>>> MBW_MAX hard limit is the only one. But the infrastrucutre supports
>>> multiple configurations per control.
>>>
>>> schemata:
>>> MB:1=100 <-- MBW_MAX on L3 id 1
>>> MB_MAXHLIM:1=0 <-- turn on/off MBW_MAX hardlimit on L3 id 1
>>> L3:1=fff
>>>
>>> info/
>>> ├── MB
>>> │ ├── bandwidth_gran
>>> │ ├── delay_linear
>>> │ ├── min_bandwidth
>>> │ ├── num_closids
>>> │ └── resource_schemata
>>> │ ├── MB
>>> │ │ ├── configs
>>> │ │ │ └── MB_MAXHLIM
>>> │ │ │ └── type <--- bool
>>> │ │ ├── max
>>> │ │ ├── min
>>> │ │ ├── resolution
>>> │ │ ├── scale
>>> │ │ ├── scope
>>> │ │ ├── status
>>> │ │ ├── tolerance
>>> │ │ ├── type
>>> │ │ └── unit
>>> │ └── mode
>>>
>>>
>>> Is this a valid way to handle MB_MAX hard limit (and future more configurations per control)?
>> It is possible but it does look very complicated to me when compared to using the control name to
>> express relationship between control and configuration.
>
> This configuration is similar to "event_configs" in "MB_MON":
> └── MB_MON
> ├── available_mbm_cntrs
> ├── event_configs
> │ └── mbm_total_bytes
> │ └── event_filter
> ├── mbm_assign_mode
> ├── mbm_assign_on_mkdir
> ├── mon_features
> ├── num_mbm_cntrs
> └── num_rmids
>
> So it's not a brand new info hierarchy. Both of configs change a resource contorl/monitor. It's just for "MB" not for "MB_MON".
>
> What do you think?
I see what you display as what we agreed on so far with the foundational "resource_schemata" or "schemata"
directory mapping to "event_configs", the subdirectories (like "mbm_total_bytes") mapping to the
controls and "event_filter" being the only property that in this feature can be writable.
Reinette