Re: [RFC PATCH 0/8] arm,x86,fs/resctrl: Support asymmetric L2 cache allocation

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

Hi Tony,

On 10/27/26 10:41 AM, Luck, Tony wrote:
> On Mon, Oct 26, 2026 at 03:30:57PM -0700, Reinette Chatre wrote:
>> Hi Tony,
>>
>> On 10/26/26 2:57 PM, Tony Luck wrote:
>>> RFC patch series built on top of Reinette's multiple control series[1]
>>>
>>> The goal is to support L2 cache allocation on hybrid Intel CPUs such as
>>> Panther Lake[2] where the P-core and E-core CPUs have different number
>>> of supported bits for L2 cache bit mask controls. N.B. it is assumned
>>> that the only point of asymmetry is the cache bit mask length. Other
>>> parameters must be the same (but code doesn't check).
>>>
>>> Overall approach is to add the per-L2 cache bitmask length to the domain
>>> and use that everywhere instead of using a single value from the control.
>>>
>>> Patch 1 changes the format of the per-control "max" file and should be
>>> merged back into Reinette's multi-control series so this file can have
>>> a consistent format from first upstream introduction.
>>>
>>> Patches 2-5 are enumeration and preperation.
>>>
>>> Patch 6 introduces, initializes, and uses the per-domain cache bit mask
>>> length field (arm/MPAM change needs careful scrutiny).
>>>
>>> Patch 7 enables asymmetric L2 for x86 CPUs that enumerate it. N.B. it
>>> renammes the resource from "L2" to "L2A" to avoid user interface issues
>>> with tools that expect L2 cache allocation to be symmetric.
>>
>> I did a quick scan and it seems to ignore the the distinction between a resource
>> and control as highlighted the previous time you brought up this work. Specifically,
>> please see:
>>
>> 	https://lore.kernel.org/lkml/eaeb4259-46d6-4656-8354-669ad32654b5@intel.com/
> 
> I think I see now. You want the "asymmetry" to be a property of the
> control, not of the resource.

Asymmetry could be a property of the resource but this is not what this proposal
does. This proposal creates a new L2 resource under a different name when resctrl
already has an L2 resource.

> 
> So the resource name stays as "L2" but the control gets a suffix (e.g.  "_ASYM")

For a new control this is reasonable, but since L2 is a legacy resource it is
expected to have a control with the same name as the resource to not break
user space. This is what I aimed to highlighted in the previous thread.

> 
> File system looks like this:
> 
> # tree
> .
> ├── cpus
> ├── cpus_list
> ├── info
> │   ├── L2
> │   │   ├── bit_usage
> │   │   ├── control_mode
> │   │   ├── min_cbm_bits
> │   │   ├── num_closids
> │   │   ├── schemata

This needs an L2 control. As I highlighted in 

	https://lore.kernel.org/lkml/22ecec13-a703-414e-9f5e-75c89173e845@intel.com/

when considering pqos utility user space expects an L2 schemata file entry
when there is an L2 resource.

Since L2_ASYM is the native interface it could be used to emulate the legacy L2 control
albeit with poor performance. By default the schemata file only contains the L2 control
and a user space familiar with new interface can enable L2_ASYM to replace L2 control
in schemata file.

When I mentioned this before you referred to it as:
	"I'm not seeing a market for the legacy behavior, so implementing it
	would just add complexity to resctrl without any benefit to users."

	https://lore.kernel.org/lkml/as6Y72SbiXcJh6Ei@agluck-desk3/

I aimed to highlight in that discussion that users depend on this behavior.

> │   │   │   └── L2_ASYM
> │   │   │       ├── max
> │   │   │       ├── min_bits
> │   │   │       └── type
> │   │   ├── shareable_bits
> │   │   └── sparse_masks
> │   └── last_cmd_status
> ├── mode
> ├── schemata
> ├── size
> └── tasks
> 
> and the schemata file:
> 
> # cat schemata
>     L2_ASYM:0=fff;1=fff;2=fff;3=fff;4=ffff;5=ffff;8=ffff

If there is a L2 resource then schemata file should only contain L2_ASYM if user space
indicates familiarity with new interface.

> 
>>
>> Also, why does patch #1 drop the 0x prefix from new control interface when displaying hex
>> values to user space? This is a significant change for which patch #1 does not provide
>> a motivation.
> 
> Sorry for missing out the justification. I thought that matching the
> format of the schemata file would be more useful. Then someone could
> reset a group to maximum values with:
> 
> # echo L2_ASYM:$(cat /sys/fs/resctrl/info/L2/schemata/L2_ASYM/max) >  schemata
> 
> But if you like the "0x" prefixes I'm OK with that too. Just need to
> replace "cat" with "sed -e s/0x//g" to reset to maximum values.
CBM writes to schemata file accepts 0x prefix, no?

The 0x prefix is from the original interface proposal that aims support
generic parsing:
	https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/

I see your point about matching the schemata file though. Now that the max is
per domain it really does resemble the schemata entry more closely. The bitmap
max could thus be expected to match the schemata entry more closely, forcing us to
carry this display decision into the new interface.

Reinette