Re: [RFC v2] arm,x86,fs/resctrl: Generic schema description Proof of Concept

Hi Reinette/Ben,

On 8/7/2026 10:35 AM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 8/7/26 7:14 AM, Moger, Babu wrote:
>> On 8/6/2026 12:11 PM, Reinette Chatre wrote:
>>> On 8/6/26 10:04 AM, Luck, Tony wrote:
>>>> On Wed, Aug 05, 2026 at 04:57:04PM -0700, Reinette Chatre wrote:
>>>>> On 8/5/26 9:59 AM, Ben Horgan wrote:
>>>>>> Just given a go at running this on a model with MPAM and I can mount resctrl with this
>>>>>> small patch to initialise the emulated_by lists so that list_empty() behaves.
>>>>>>
>>>>>> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
>>>>>> index 21dcbf5764cc..638095649151 100644
>>>>>> --- a/drivers/resctrl/mpam_resctrl.c
>>>>>> +++ b/drivers/resctrl/mpam_resctrl.c
>>>>>> @@ -1018,6 +1018,7 @@ static int mpam_resctrl_control_init(struct mpam_resctrl_res *res)
>>>>>>           case RDT_RESOURCE_L3:
>>>>>>                   mpam_ctrl->r_ctrl.type = RESCTRL_CTRL_BITMAP;
>>>>>>                   mpam_ctrl->r_ctrl.name = RESCTRL_CTRL_NAME_DEF;
>>>>>> +               INIT_LIST_HEAD(&mpam_ctrl->r_ctrl.emulated_by);
>>>>>>                   INIT_LIST_HEAD_RCU(&mpam_ctrl->r_ctrl.domains);
>>>>>>                   __set_bit(RESCTRL_BITMAP_FLAG_SPARSE, mpam_ctrl->r_ctrl.bitmap.flags);
>>>>>>                   mpam_ctrl->r_ctrl.bitmap.cbm_len = class->props.cpbm_wd;
>>>>>> @@ -1048,6 +1049,7 @@ static int mpam_resctrl_control_init(struct mpam_resctrl_res *res)
>>>>>>                   r->ctrl_scope = RESCTRL_L3_CACHE;
>>>>>>                   mpam_ctrl->r_ctrl.type = RESCTRL_CTRL_SCALAR;
>>>>>>                   mpam_ctrl->r_ctrl.name = RESCTRL_CTRL_NAME_DEF;
>>>>>> +               INIT_LIST_HEAD(&mpam_ctrl->r_ctrl.emulated_by);
>>>>>>                   INIT_LIST_HEAD_RCU(&mpam_ctrl->r_ctrl.domains);
>>>>>>
>>>>>>                   r->bw_throttle_mode = THREAD_THROTTLE_UNDEFINED;
>>>>>
>>>>> Thank you for this. Added this and it is now available in branch resctrl/controls_rfc_v2.1
>>>>
>>>> Is same needed for x86? I don't see any initialization of the
>>>> "r_ctrl.emulated_by" lists in similar initialization functions.
>>> x86 "emulated_by" list initialization should be in both branches.
>>>
>>> Branch resctrl/controls_rfc_v2.1 combined all "emulated_by" list initialization
>>> (for x86 and MPAM) into commit:
>>> 3407e523c988 ("fs/resctrl: Introduce emulated controls and control mode")
>>>
>>> In the original resctrl/controls_rfc_v2 the x86 "emulated_by" list initialization can
>>> be found in commit fbed64f80515 ("x86/resctrl: SAMPLE: Emulated controls")
>>>
>>
>> Looking at the commit:
>>
>> commit 3407e523c988 ("fs/resctrl: Introduce emulated controls and control mode")
>>
>> Based on the patch description, emulated controls are intended to be
>> used only when there is a difference between the native and legacy
>> controls. If no such difference exists, both modes should operate
>> identically.
> 
> The original AMD MBA enabling did not follow the original percentage based MBA
> control so resctrl essentially has *two* "legacy" MB controls today: one for AMD
> and one for Intel, MPAM, and RISC-V (planned afaik). That cannot be changed now.
> AMD would continue to expose the MB control that is not the percentage based "legacy"
> control but actually AMD's native control. In short, yes, on AMD's "MB" control
> the "legacy" and "native" control modes should operate identically.
> At least now users could use the files in info/MB/schemata/MB/* to learn the
> properties of the control.
>> For MBA(AMD) and GMBA, there does not appear to be any difference
>> between the two modes. Is that understanding correct?
> It is not clear to me how resctrl should support AMD's GLBE. Note I am intentionally
> not using GMBA since that already makes an assumption on how resctrl will support this.
> Do you perhaps have an answer for Ben's question in
> https://lore.kernel.org/lkml/[email protected]/ ?

Yes. We are already at RFC v2. Let me respond here. Please see my 
response below.

> 
> GLBE claims to enable users to allocate memory bandwidth at node scope but the memory
> is managed at L3. This results in scenarios where, for example, a NUMA node can be
> online and used but resctrl cannot expose it for bandwidth allocation when all the CPUs
> at that NUMA node scope are offline. GLBE is thus not actually allocating memory bandwidth
> at the NUMA node.

Yea. That is correct.

There are a couple of key differences when compared to the pure NUMA scope.

1. In some cases, a NUMA node is treated as the entire system.

  
https://lore.kernel.org/lkml/8f77f498b1c77fa8fd8f5d5687f03ae598068544.1776980182.git.babu.moger@amd.com/

2. When a user updates the settings on a GLBE for a specific node, we 
need to update the MSRs within that node at the L3 scope:

https://lore.kernel.org/lkml/a2a06bd290e68f902be9e7cc3ad35f0a2211b950.1776980182.git.babu.moger@amd.com/


Considering these differences, I think we should probably treat GLBE 
separate from MB_NODE scope. What do you think?


> 
> Should resctrl prepare for some future where an AMD system may support memory bandwidth
> allocation at the NUMA node while also supporting GLBE (memory bandwidth allocation at L3)?

No, I don't believe that's the case. At least, I haven't come across any 
information suggesting that.

Thanks,
Babu