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

[Drew Fustini]

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?

Thanks,
Drew

[1] https://lore.kernel.org/all/20260601-ssqosid-cbqri-rqsc-v7-0-v6-0-baf00f50028a@xxxxxxxxxx/