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

[Babu Moger <babu.moger@amd.com>]

Hi Reinette,

On 6/2/26 22:55, Reinette Chatre wrote:
> Hi Babu,
> 
> On 6/2/26 6:14 PM, Moger, Babu wrote:
>> Hi Reinette,
>>
>> On 6/2/2026 5:56 PM, Reinette Chatre wrote:
>>> 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@intel.com/
>>
>> Yes. It works. But, I used to find patches using the names. It did not work this time.
> 
> Interesting. When I run your lore query the first email from this thread is among the
> results.
> 
>>
>>>
>>>>
>>>> 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?
>>>
>>
>> Thanks for the sketch. It makes it much more clear.
>>
>> mon_domains directly maintains a list of monitoring domains, whereas controls maintains a list of control objects, each of which owns its own domain list.
>>
>> I was thinking, one possibility would be to make mon_domains follow a structure similar to controls, allowing both to be represented through a common top-level list.
>>
>> However, the resulting abstraction may become fairly large and complex, with limited overlap between the monitoring and control data structures.
>>
> 
> I am trying to envision this but it sounds to be as though each control has its own monitoring
> which is not clear to me. resctrl ultimately needs to support hardware features. Could you please
> share more about the hardware feature(s) this design intends to support?
> 

This is mostly my thinking. There is no new hardware feature that 
required this change. We can safely ignore this idea.

Thanks
Babu