Re: [BOF]arm: resctrl: L3 cache partitioning via CLUSTERPARTCR

[James Morse]

Hi Aiqun,

On 30/06/2026 12:48, Aiqun(Maria) Yu wrote:
> L3 cache partitioning is an important feature for improving performance
> isolation of latency-sensitive tasks. While ARM MPAM provides a
> comprehensive solution,

> there exists another ARM register, CLUSTERPARTCR,

It's important to note this isn't an ARM architecture feature or register,
it's part of one version of DSU, which is a shared-cache IP in some designs.


> which offers L3 cache partitioning functionality similar to MPAM's CPBM
> (Cache Portion BitMask) but is not part of the MPAM architecture.

... and as its not part of any architectural feature, is going to be very hard
to use.


> CLUSTERPARTCR is a cluster-level register that allows software to partition
> L3 cache capacity among different workloads. Although its partitioning
> granularity and flexibility are more limited compared to full MPAM support,
> it remains a practically important interface for platforms that do not
> implement MPAM but still need L3 cache partitioning capability.

This stuff is designed for static SoC configurations. e.g. CPU-4 is running
your modem stack. I don't this is going to work well with general purpose
things like linux and resctrl.


> This raises the following questions for the community:
> 
>   1. Is there interest in accommodating CLUSTERPARTCR-based L3 partitioning
>      within the existing resctrl framework, given that it provides similar
>      semantics to Intel RDT's cache allocation technology (CAT)?

I'd say that is impossible.

This would rely on accessing implementation defined system registers, not just
in some driver - but in the architecture's context-switch path. This has been a
hard no in the past. For just the imp-def part, see: [0][1][2]

Doing this doesn't virtualise as all those registers are trapped by HCR_EL2.TIDCP,
the hypervisor can't emulate these registers as they can behave differently on
each CPU. The only option is to emulate an undefined instruction exception.
This makes detecting the SoCs where this could be used very difficult.


>   2. Alternatively, would it be more appropriate to integrate it under the
>      MPAM resctrl framework as a non-MPAM backend, given the functional
>      similarity to MPAM CPBM?

I don't think its at all similar.

This doesn't map to the L3/CPBM bitmap schema. A group is 4 ways, and the control
is only to make a group private to an 'ID'. You can't share a group between two
resctrl groups - which the bitmap schema allows.

As an ugly corner case: if you tried to express the groups as a bitmap, a 12-way
cache configuration would have 3 groups - meaning a two bit bitmap has invalid values.

This is all because its not really a bitmap in hardware.


The datasheet/TRM you linked doesn't say that the partition controls can be changed
at runtime. Resctrl requires this.
While the document doesn't say either way - its very common for interconnect IP to
expect configuration information to only be written to during power-on, when there
is no traffic flowing in the system. Linux can't ever do this.


>   3. Are there any concerns or constraints in the current resctrl/MPAM
>      framework that would prevent such an integration?

Not just the imp-def system registers: There is no way of detecting whether
this is present in any particular SoC. You can't have a table of SoCs where
it happens to be as it also depends on the EL3 firmware to turn this interface
on, and a hypervisor not being present.

The system registers imply some knowledge of the topology, its not just which
CPUs share a DSU,  but where an 'ACP' goes, and what a 'STASH' is for.


It looks like there are 8 'partition scheme IDs', but only 'four private L3 cache
partitions can be created' - so depending on what is written to the schema file,
there may be only four control groups usable.


> Any comments, suggestions, or pointers to prior discussion on this topic
> are very much appreciated.
I don't think this is workable for either resctrl or the architecture code.

DSU supports MPAM, so presumably this is for an older version that doesn't have the
MPAM feature?


Thanks,

James

[0] https://lore.kernel.org/linux-arm-kernel/20151026124616.GB9740@leverpostej/
[1] https://lore.kernel.org/linux-arm-kernel/20201120101249.GA2328@C02TD0UTHF1T.local/
[2] https://lore.kernel.org/linux-arm-kernel/20210108125410.GA84941@C02TD0UTHF1T.local/