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

[Reinette Chatre]

Hi Drew,

On 6/3/26 3:14 PM, Drew Fustini wrote:
> On Fri, May 29, 2026 at 11:06:07AM -0700, Reinette Chatre wrote:
>> /**
>>  * 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.
> 
> The ability to change scope is much needed for RISC-V. There are
> compromises in my RFC [1] as a result of trying to map everything to
> either L2 or L3 scope.
> 
> I would also like to see a non-cpu cache scope for monitoring too, but
> would that be better discussed outside the context of this proof of
> concept?

I also think it would be good for it to be clear that monitoring is based on
scope, not a resource. With the MB controls supporting different scope I do think
that this would be a good next step. A previous musing from me on this topic can
be found (at the end of ) https://lore.kernel.org/lkml/fb1e2686-237b-4536-acd6-15159abafcba@xxxxxxxxx/

I have not yet considered how this can be built on top of this PoC though.

Reinette