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

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

Hi Chenyu,

On 6/3/26 4:53 AM, Chen, Yu C wrote:
> Hi Reinette,
> 
> On 6/3/2026 11:45 AM, Reinette Chatre wrote:
>> Hi Chenyu,
>>
> 
> [ ... ]
> 
>>>
>>> Thanks for re-spinning this patch set.
>>> Looking at commit (fs/resctrl: Introduce additional schema properties),
>>> the newly added properties appear to be implemented for the
>>> MBA resctrl_membw controller.
>>
>> Please do note that the "struct resctrl_membw" naming is temporary. I only kept
>> current naming to help folks find where existing known structures land in this new
>> design but the "struct resctrl_membw" name is not appropriate moving forward.
>>
>> When user space interacts with the new controls the intention is that each control
>> has a "type" that the user can find in the new "type" file and depending on that value
>> the user will know what other files/properties can be expected.
>>
>> In this PoC there are two types: "scalar" and "bitmap" and each is associated with
>> a struct that contains the properties associated with that type.
>>
>> Considering this, these structures could, for example, be renamed as (very long):
>> struct resctrl_membw -> struct resctrl_ctrl_scalar
>> struct resctrl_cache -> struct resctrl_ctrl_bitmap
>>
> 
> OK, the type field serves as the primary key for querying other properties.
> Alongside the "type" entry, there also exists a "flag" property. I haven't
> spotted this field within resctrl_membw, though it appears in resctrl_cache
> via arch_has_sparse_bitmasks. Would it make sense to introduce a dedicated
> enum for this flag, or alternatively reuse the existing bw_delay_linear for MBA?

I realize now my previous answer to you was incomplete. You are right that there
is a plan to let the resctrl "type" file contain the schema type as well as
optional flags. This plan is unchanged but at this time it is not obvious to me
what flags this implementation should start with.

In the original proposal [1] "linear" was provided as example of a flag for the MB
resource but as I worked through this PoC whether a control is linear or not seemed
to fit better as a resource property. This is how I ended up with commit
bdcd8ac6e946 ("mpam,x86,fs/resctrl: Make memory bandwidth delay a resource property")

For this specific property I expect that all controls would have the same value. This
worked out well since resctrl already has the per-resource top level "delay_linear".

We can surely move this back to be a control property and have it be the first
"flag" but at this time it seems to me that all MB controls would just have the same
flag value?

Perhaps the safest alternative would be to keep it a resource property and just duplicate
this as a flag value among all the controls? I think this is what you are suggesting to
reuse the bw_delay_linear for MBA. This would not result in dedicated flags associated
with controls but it may set the user interface up for most flexibility. 

Reinette

[1] https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/