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

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

Hi Chenyu,

On 6/5/26 8:43 AM, Chen, Yu C wrote:
> Hi Reinette,
> 
> On 6/5/2026 12:37 AM, Reinette Chatre wrote:
> 
> [ ... ]
> 
>>>
>>> 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.
>>
> 
> Yes I think we can simply reuse the value of bw_delay_linear when displaying the
> "flag" field for each controller under the info directory.
> BTW, would the L3 controller have similar case that, all L3 controllers of the same
> resource share the same value of "flag"? If yes, should we also move arch_has_sparse_bitmasks
> to rdt_resource? If yes, I'm not sure why we need "flag" in the controller.
Whether a control of type bitmap allows sparse values or not does seem to be a valid
property of the bitmap control to me. It is difficult to predict how this will land since
I am not familiar with a resource that has multiple bitmap controllers.

I do think having a controller type support different flags in the interface exposed to the
user does give resctrl most flexibility for the future. With the user interface having that
capability the internal implementation can always adapt.

Reinette