Re: [PATCH v7 2/5] riscv_cbqri: resctrl: Add cache allocation via capacity block mask

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

Hi Tony,

On 10/12/26 10:31 AM, Luck, Tony wrote:
> On Thu, Sep 17, 2026 at 08:57:10AM -0700, Luck, Tony wrote:
>> On Thu, Sep 17, 2026 at 08:37:43AM -0700, Reinette Chatre wrote:
>>> On 9/1/26 3:31 PM, Drew Fustini wrote:
>>>> resctrl exposes a single cap set per rid, so when more than one capacity
>>>> controller backs a cache level they must agree on those caps. A level
>>>> whose controllers disagree is left unexposed. Other levels are
>>>> unaffected.
>>> If I understand correctly, while attempting to translate to resctrl terms,
>>> this means that a cache resource with several domains may support different
>>> capacity masks in the domains?
>>>
>>> I believe the "single cap set per rid" you refer to is
>>> /sys/fs/resctrl/info/L3/cbm_mask and /sys/fs/resctrl/info/L2/cbm_mask that
>>> exposes a single capacity bitmask representing the maximum allocation.
>>>
>>> As you know, resctrl is in the process of changing the way in which schema
>>> formats are described. The most recent PoC [1] added new bitmap description
>>> files but it kept a single value "max" file to describe the highest allocation
>>> possible for a bitmap schema.
>>>
>>> To support asymmetrical cache instances it looks like changing the interface
>>> to describe the maximum per domain (instead of one global value) could address
>>> the gap?
>>>
>>> For example, if there is a hypothetical system with two L2 cache instances, one
>>> with a 0xFF max CBM and the other with a 0XF max CBM then resctrl could expose it
>>> as:
>>
>> That sounds like the not-at-all-hypothetical Intel hybrid client parts
>> where P-core and E-core have different L2 masks.
>>
>>>
>>> 	# cat /sys/fs/resctrl/info/L2/schemata/L2/max
>>> 	0=ff;1=f
>>>
>>> The schemata file currently and will continue to display the allocations per domain.
>>>
>>> resctrl will need more changes to support different CBM per domain internally and
>>> until then all these CBMs will be the same, but adding this change to user interface now
>>> may set resctrl up to support these systems in the future?
>>
>> I think Fenghua once worked on patches to support this. But I don't
>> think they were every posted to LKML. One of the open issues at the time
>> was how to handle the info/L2/cbm_mask file.
> 
> I took git://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git
> branch resctrl/controls_rfc_v2.4 and added some patches to support L2
> per-domain cache allocation bitmasks. Seems to be working OK. I can
> share the patches if anyone is interested, but they aren't even up to
> RFC quality yet.
> 
> I do have some questions:
> 
> 1) The repeated "L2" in the path seems awkward. The first is the
> resource name, the second the control name. Makes sense for MBA where
> there may be multiple control names. But for cache ... is there a better
> name for the control than repeating the resource name?

If we are using the same definitions of what a control and resource represents: no.

A control is represented by an entry in the schemata file and is what the
user interacts with to configure resource allocation. Today there is a 1:1
relationship between a resource and its only control and today this control
has the same name as the resource. This is not something we can change at
this point for a legacy resource like "L2" since it is already represented
in the schemata file by a control named "L2".

Multiple controls is not just for MBA. There will also be multiple cache controls.
For reference:
https://lore.kernel.org/lkml/20260921135702.2874931-1-ben.horgan@arm.com/

All "legacy" resource have a control with the same name as the resource. At this
point this is not required for new resources with first resource like this planned
to be MB_NODE.
> 2) Should the format of /sys/fs/resctrl/info/L2/schemata/L2/max depend
> on whether the platform is asymmetric? Or just enumerate the per-domain
> values even on symmetric systems? Likely easier for users to list all
> domains.

If it depends on the platform then resctrl would need to separately let user
space know whether the platform is asymmetric or not. This additional information
seems unnecessary if the only motivation is to let user know if the max values
are per-domain or not. Always listing all domains seems to be the simplest and
straightforward option.
> 3) What should happen to the legacy /sys/fs/resctrl/info/L2/cbm_mask?
> Just hide it? I also considered renaming the resource to "L2A" to
> avoid surprising legacy code.
The current direction is to have these top level files continue to return
the properties of the default/legacy control while in "legacy" control mode.
When user space switches the control mode then these files return empty. 

This is what is implemented in RFC v2 so you should be able to see it in action.

It was noted as one of RFC v2's opens:
	- When switching control mode to native the top level control info files
	  stop returning information. This could be considered "work as intended"?

An example of this behavior in action as applied to "min_bandwidth" can be seen 
on slide 4 of
https://lpc.events/event/20/contributions/2368/attachments/2066/4625/resctrl_2026_combined.pdf

Hiding the files could also be an option. I have not heard strong opinions on how this
should be handled after the above mentions of current direction.

Reinette