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

["Luck, Tony" <tony.luck@intel.com>]

On Tue, Oct 13, 2026 at 10:42:05AM -0700, Reinette Chatre wrote:
> 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?

The control (though with only one control in the L2 resource its effectively the resource too).

> 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,

The system I'm working on has L2 caches that appear like this:

	    L2:0=fff;1=fff;2=fff;3=fff;4=ffff;5=ffff;8=ffff

The P-cores support 12 ways in their L2 caches, the E-cores support 16 ways
in each of the per-module L2 caches.

A legacy implementation would have to present just 12 ways across all
domains to the user. The implementation of that has a couple of choices:

1) Ignore 25% of the caches on the E-cores.
	Unlikely to please anyone.
2) Silently allow access to the "f000" ways of the E-core caches.
	Doesn't waste the hardware, but if the user tries to divide
	available cache exclusively between groups, the "free" extra
	cache would result in surprise sharing.

The drive for L2 controls on hybrid systems comes from embedded systems
where expectations would be for the controls to operate precisely as
written without any fuzziness.

I'm not seeing a market for the legacy behavior, so implementing it
would just add complexity to resctrl without any benefit to users.

Perhaps keep the "L2" resource name. Use "L2" for a control name for
symmetric systems. Use "L2A" as the control name for asymmetric systems.
Legacy software won't be confused because there won't be an "L2:"
line in the schemata file.

Don't bother with a control_mode to switch between legacy and native.
Just auto-select the "L2A" control on asymmetric systems.

But since this thread started from a RISC-V thread, it would be good to
hear what is needed for RISC-V.

-Tony