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/13/26 8:55 AM, Luck, Tony wrote:
>>> 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.
> 
> My PoC hasn't implemented anything for the control_mode file so I get this:
> 
> $ cat L2/control_mode
> [legacy] native
> $ sudo sh -c "echo native > L2/control_mode"
> sh: 1: echo: echo: I/O error
> $ cat last_cmd_status
> Changing control mode not supported for this resource.

The current PoC supports multiple controls for cache resources but does not
support switching to native control mode. Only MBA resource can switch to native
control mode.

resctrl fs built a couple of features on top of cache allocation that are exposed
to user space (CDP, IO allocation, and pseudo-locking). It still needs to be worked
out how these behave when there is no legacy cache control so for now these features
are hardcoded to be associated with the legacy cache control and switching to
native mode is disabled.

> 
> But it isn't clear to me what legacy vs. native should mean for asymmetric L2.

This would be up to the architecture. One possibility is to have the asymmetric
L2 control emulate the legacy L2 cache control. I did not really consider this
and just assumed the legacy control could be expanded to support different sized
domains. 
> Potentially: Legacy mode: L2 is disabled to avoid confusion with different bitmasks per domain?
For "L2 is disabled", are you referring to the resource or the control?

If legacy L2 control can be emulated by the asymmetric L2 control then a user space
can continue to interact with a L2 control that pretends to be symmetric on an
asymmetric platform. An "enlightened" user space can then switch to native control mode
on these systems and interact with the asymmetric control directly.

I am not sure that this is what RISC-V has in mind here though.

Ideally user space would not need to be exposed to architecture differences when
interacting with resctrl filesystem. This means that a solution like this would
force all architectures to do something similar for asymmetrical/symmetrical
cache allocation.

Another option is to just support L2 asymmetric systems with the legacy L2 control.
You state it may cause confusion - I assume you refer here to the schemata file
showing different CBM for different domains? The legacy info/L2/cbm_mask needs to
pick one CBM to display, which could be limiting. This is what the new "max"
aims to fix. 

Reinette