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

["Chen, Yu C" <yu.c.chen@intel.com>]

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.

thanks,
Chenyu