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

[Reinette Chatre <reinette.chatre@intel.com>]

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/1444b515-752e-4167-87f5-30ace189e05c@arm.com/ ?

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.

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)? 

Reinette