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

[Reinette Chatre]

Hi Babu,

On 6/2/26 1:23 PM, Babu Moger wrote:
> Hi Reinette,
> 
> For some reason, I couldn’t find your patch on lore.kernel.org:
> https://lore.kernel.org/lkml/?q=Reinette+Chatre

How about:
https://lore.kernel.org/lkml/aab804b9-e8b5-40ad-a85b-af7033391243@xxxxxxxxx/

> 
> I eventually located it here:
> https://sashiko.dev/#/message/aab804b9-e8b5-40ad-a85b-af7033391243%40intel.com
> 
> Thanks for sharing the patches. I’m still reviewing them.
> 
> I was able to build and boot the kernel and can see the MIN and MAX controls. After moving your test code to __rdt_get_mem_config_amd().

Thank you very much for trying it out.

> On 5/29/26 13:06, Reinette Chatre wrote:

...

>> Primary resctrl fs data structure changes
>> =========================================
>>
>> Introduces a control represented by struct resctrl_ctrl that looks as below. To make
>> the changes easier to follow I kept some of the original names to help communicate
>> where familiar data structures land.
>>
>> What to notice about a control is that it has some common properties required
>> from all controls (scope, type, etc.) and then depending on the type of control
>> (RESCTRL_CTRL_BITMAP or RESCTRL_CTRL_SCALAR) there are type specific properties.
>>
>> /**
>>   * struct resctrl_ctrl - A resource control
>>   * @entry:    List entry of rdt_resource::controls
>>   * @scope:    Scope of the resource that this control allocates
>>   * @domains:    RCU list of all control domains
>>   * @type:    The control type that determines the properties of the control,
>>   *        format string for displaying control values to user space, and
>>   *        parser of control values provided by user space.
>>   * @name:    Name of the control. Appended to final resource name
>>   *        (rdt_resource_final::name) to create final schema entry.
>>   *        Specifically, "rdt_resource_final::name"_"resctrl_ctrl::name".
>>   *        For example, with resource name "MB" and control name "MAX" the
>>   *        schema entry will be "MB_MAX".
>>   * @cache:    Cache allocation control properties.
>>   * @membw:    Bandwidth control properties.
>>   */
>> 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_cache    cache;
>>         struct resctrl_membw    membw;
>>     };
>> };
>>
>> Two members summarize how this new structure fits into the rest of resctrl:
>> a) resctrl_ctrl::entry
>>     Since a resource can support multiple controls there is a new list
>>     in struct rdt_resource named "controls" that contains the list of all
>>     controls supported by the resource.
>> b) resctrl_ctrl::domains
>>     Instead of the list of control domains belonging to a resource they
>>     now belong to the control self. By doing so resctrl can support resource
>>     controls at different scope for the same resource. This is intended to
>>     support some upcoming MPAM and RISC-V usages.
>>     
> 
> I like the idea of supporting multiple controls for each resource.
> 
> With these patches, now we have one list containing all the controls.
> 
> However, in case of RDT_RESOURCE_L3, we have two lists "mon_domains" and "controls". mon_domains list deals with monitoring and control deals with control parts(multiple).
> 
> Have you thought about making the list("control") generic so that the control can be monitoring also. It will just one list containing multiple controls or monitor.

The control list adds an additional layer of abstraction just for control management,
independent from monitoring. The mon_domains list is unchanged while each control now
has its own ctrl_domains list. 

Here is an attempt to visualize how a resource with two monitoring domains, and two controls,
each with two control domains end up being managed:

+-------------------------+
| struct rdt_resource     |
+-------------------------+
| ...                     |
| controls (list_head)    |---------+
| mon_domains (list_head) |---+     |
| ...                     |   |     |
+-------------------------+   |     |
                              |     |
  +---------------------------+     |
  |                                 |
  v                                 v
+-----------------------------+   +-------------------------+
| struct rdt_l3_mon_domain #1 |   | struct resctrl_ctrl #A  |
+-----------------------------+   +-------------------------+
| rdt_domain_hdr              |-+ | entry (list_head)       |       +----------------------------+
| ...                         | | | domains (list_head)     |------>| struct rdt_ctrl_domain #A1 |
+-----------------------------+ | | ...                     |       +----------------------------+
                                | +-------------------------+       | rdt_domain_hdr             |---+
  +-----------------------------+   |                               | ...                        |   |
  | (next)                          | (next)                        +----------------------------+   |
  v                                 v                                                                |
+-----------------------------+   +-------------------------+       +----------------------------+<--+
| struct rdt_l3_mon_domain #2 |   | struct resctrl_ctrl #B  |       | struct rdt_ctrl_domain #A2 |
+-----------------------------+   +-------------------------+       +----------------------------+
| rdt_domain_hdr              |   | entry (list_head)       |       | rdt_domain_hdr             |
| ...                         |   | domains (list_head)     |----n  | ...                        |
+-----------------------------+   | ...                     |    |  +----------------------------+
                                  +-------------------------+    |
                                                                 |
                                    +----------------------------+
                                    |
                                    v
                                  +----------------------------+
                                  | struct rdt_ctrl_domain #B1 |
                                  +----------------------------+
                                  | rdt_domain_hdr             |---+
                                  | ...                        |   |
                                  +----------------------------+   |
                                                                   |
                                  +----------------------------+<--+
                                  | struct rdt_ctrl_domain #B2 |
                                  +----------------------------+
                                  | rdt_domain_hdr             |
                                  | ...                        |
                                  +----------------------------+

resctrl used to manage single domains that are capable of both monitoring and control
but this was split to support scenario where monitoring and control of a resource are
done at different scope. See
cd84f72b6a5c ("x86/resctrl: Prepare for different scope for control/monitor operations")

This feature further expands the difference between monitoring and control since now there
can be multiple instances of a control domain (one per control) associated with a resource
while monitoring still just supports one monitoring domain per resource.

I thus cannot see how this can be accomplished with a single list. Could you sketch out
what you have in mind?

...

>>
>> Patch 54:
>> Teach resctrl fs about "MIN" and "MAX" controls.
>>
>> Patch 55:
>> Sample of "MIN" and "MAX" memory bandwidth controls for x86.
> 
> My assumption is that the MIN and MAX controls here are just examples, correct?
> 
> You only mentioned patch 55 as "NOT_FOR_INCLUSION". I assume patch 54 should also be marked as "NOT_FOR_INCLUSION"?

While patch 55 is the first and only "user" of patch 54 I believe that patch 54 (or some variant
of it) will stay since we already know that both MPAM and Intel need to support min and max controls.

Reinette