[PATCH v5 0/2] selftests/resctrl: Fix resctrl selftests issues on aarch64

[PATCH v5 0/2] selftests/resctrl: Fix resctrl selftests issues on aarch64

[Richard Cheng]

This series fixes issues in the resctrl selftests on aarch64,
where they currently misreport failures.

Patch 1 adds aarch64 implementations of cl_flush() and sb() in
fill_buf.c so cache flushes are no longer silent no-ops.

Patch 2 teaches detect_vendor() about aarch64 (which exposes no
vendor_id in /proc/cpuinfo) and lets arch_supports_noncont_cat()
return true for ARM, fixing spurious L3_NONCONT_CAT failures.

Changes since v4:
- Drop v4 patch 1/3, which was applied to linux-kselftest/next.
- Rebase the remaining patches onto linux-kselftest/next and
  renumber v4 patches 2/3 and 3/3 as patches 1/2 and 2/2.
  No code changes to the remaining patches.

Richard Cheng (2):
  selftests/resctrl: Implement cl_flush() and sb() for aarch64
  selftests/resctrl: Recognise aarch64 as a vendor for L3_NONCONT_CAT

 tools/testing/selftests/resctrl/cat_test.c    |  9 ++++++--
 tools/testing/selftests/resctrl/fill_buf.c    | 11 ++++++++++
 tools/testing/selftests/resctrl/resctrl.h     |  1 +
 .../testing/selftests/resctrl/resctrl_tests.c | 21 +++++++++++++++++++
 4 files changed, 40 insertions(+), 2 deletions(-)


base-commit: 30af56a227e27b892d34bc44c23298b5274913e3
-- 
2.43.0

[PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Richard Cheng]

cl_flush() and sb() compile to empty functions on aarch64, making
mem_flush() a silent no-op and leaving CMT/CAT tests operating on
unflushed state.

Add "dsb sy" for sb(), ARM requires a DSB whose access type covers both
loads and stores.

For cl_flush(), "dc civac" only reaches the Point of Coherency, on
ARM MPAM systems the SLC lies past the PoC and may be a NOP on coherent
platforms. Instead, dirty each cacheline with a store so that
mem_flush's full-buffer sweep evicts lines from the SLC via LRU
pressure.

Signed-off-by: Richard Cheng <icheng@nvidia.com>
---
 tools/testing/selftests/resctrl/fill_buf.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/tools/testing/selftests/resctrl/fill_buf.c b/tools/testing/selftests/resctrl/fill_buf.c
index b9fa7968cd6e..eae0262fe265 100644
--- a/tools/testing/selftests/resctrl/fill_buf.c
+++ b/tools/testing/selftests/resctrl/fill_buf.c
@@ -27,6 +27,9 @@ static void sb(void)
 #if defined(__i386) || defined(__x86_64)
 	asm volatile("sfence\n\t"
 		     : : : "memory");
+#elif defined(__aarch64__)
+	asm volatile("dsb sy\n\t"
+		     : : : "memory");
 #endif
 }
 
@@ -35,6 +38,14 @@ static void cl_flush(void *p)
 #if defined(__i386) || defined(__x86_64)
 	asm volatile("clflush (%0)\n\t"
 		     : : "r"(p) : "memory");
+#elif defined(__aarch64__)
+	/*
+	 * Dirty the cache line with a store. As mem_flush() sweeps
+	 * the full test buffer (sized larger than the SLC), cache pressure
+	 * evicts lines from the SLC via LRU replacement.
+	 */
+	asm volatile("strb wzr, [%0]\n\t"
+		     : : "r"(p) : "memory");
 #endif
 }
 
-- 
2.43.0

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Ben Horgan]

Hi Richard,

Thanks for having a look at the arm64 side of the resctrl selftests. That hasn't had much love but
it would be good to have them working properly.

On 12/10/2026 08:47, Richard Cheng wrote:
> cl_flush() and sb() compile to empty functions on aarch64, making
> mem_flush() a silent no-op and leaving CMT/CAT tests operating on
> unflushed state.
> 
> Add "dsb sy" for sb(), ARM requires a DSB whose access type covers both
> loads and stores.

I guess this is referring to the synchronization required for the cache maintenance instruction but
that's not what you are using in this patch.

> 
> For cl_flush(), "dc civac" only reaches the Point of Coherency, on
> ARM MPAM systems the SLC lies past the PoC and may be a NOP on coherent
> platforms. Instead, dirty each cacheline with a store so that
> mem_flush's full-buffer sweep evicts lines from the SLC via LRU
> pressure.
> 
> Signed-off-by: Richard Cheng <icheng@nvidia.com>
> ---
>  tools/testing/selftests/resctrl/fill_buf.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/tools/testing/selftests/resctrl/fill_buf.c b/tools/testing/selftests/resctrl/fill_buf.c
> index b9fa7968cd6e..eae0262fe265 100644
> --- a/tools/testing/selftests/resctrl/fill_buf.c
> +++ b/tools/testing/selftests/resctrl/fill_buf.c
> @@ -27,6 +27,9 @@ static void sb(void)
>  #if defined(__i386) || defined(__x86_64)
>  	asm volatile("sfence\n\t"
>  		     : : : "memory");
> +#elif defined(__aarch64__)
> +	asm volatile("dsb sy\n\t"
> +		     : : : "memory");
>  #endif
>  }
>  
> @@ -35,6 +38,14 @@ static void cl_flush(void *p)
>  #if defined(__i386) || defined(__x86_64)
>  	asm volatile("clflush (%0)\n\t"
>  		     : : "r"(p) : "memory");
> +#elif defined(__aarch64__)
> +	/*
> +	 * Dirty the cache line with a store. As mem_flush() sweeps
> +	 * the full test buffer (sized larger than the SLC), cache pressure
> +	 * evicts lines from the SLC via LRU replacement.
> +	 */
> +	asm volatile("strb wzr, [%0]\n\t"
> +		     : : "r"(p) : "memory");
>  #endif

Isn't this cl_flush() used without changing the resctrl control and monitor group (PARTID/PMG)?
Hence, I expect you are ending up making the cache full of data associated with the identifiers that
the benchmark runs with. Is that the case?

I'm also unclear how this the cat_test will detect any performance differences on arm/MPAM as the
perf events would need to specific to the system level cache implementation.

Thanks,

Ben



>  }
>  

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Ben Horgan]

Hi Richard,

On 20/10/2026 17:30, Ben Horgan wrote:
> Hi Richard,
> 
> Thanks for having a look at the arm64 side of the resctrl selftests. That hasn't had much love but
> it would be good to have them working properly.
> 
> On 12/10/2026 08:47, Richard Cheng wrote:
>> cl_flush() and sb() compile to empty functions on aarch64, making
>> mem_flush() a silent no-op and leaving CMT/CAT tests operating on
>> unflushed state.
>>
>> Add "dsb sy" for sb(), ARM requires a DSB whose access type covers both
>> loads and stores.
> 
> I guess this is referring to the synchronization required for the cache maintenance instruction but
> that's not what you are using in this patch.
> 
>>
>> For cl_flush(), "dc civac" only reaches the Point of Coherency, on
>> ARM MPAM systems the SLC lies past the PoC and may be a NOP on coherent
>> platforms. Instead, dirty each cacheline with a store so that
>> mem_flush's full-buffer sweep evicts lines from the SLC via LRU
>> pressure.
>>
>> Signed-off-by: Richard Cheng <icheng@nvidia.com>
>> ---
>>  tools/testing/selftests/resctrl/fill_buf.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/tools/testing/selftests/resctrl/fill_buf.c b/tools/testing/selftests/resctrl/fill_buf.c
>> index b9fa7968cd6e..eae0262fe265 100644
>> --- a/tools/testing/selftests/resctrl/fill_buf.c
>> +++ b/tools/testing/selftests/resctrl/fill_buf.c
>> @@ -27,6 +27,9 @@ static void sb(void)
>>  #if defined(__i386) || defined(__x86_64)
>>  	asm volatile("sfence\n\t"
>>  		     : : : "memory");
>> +#elif defined(__aarch64__)
>> +	asm volatile("dsb sy\n\t"
>> +		     : : : "memory");
>>  #endif
>>  }
>>  
>> @@ -35,6 +38,14 @@ static void cl_flush(void *p)
>>  #if defined(__i386) || defined(__x86_64)
>>  	asm volatile("clflush (%0)\n\t"
>>  		     : : "r"(p) : "memory");
>> +#elif defined(__aarch64__)
>> +	/*
>> +	 * Dirty the cache line with a store. As mem_flush() sweeps
>> +	 * the full test buffer (sized larger than the SLC), cache pressure
>> +	 * evicts lines from the SLC via LRU replacement.
>> +	 */
>> +	asm volatile("strb wzr, [%0]\n\t"
>> +		     : : "r"(p) : "memory");
>>  #endif

One more thing that occurred to me is that if this is intended to evict all existing data in the
cache then it would require that the cache portions bitmap for the control group (PARTID) in use is
set to all 1s. E.g. 'L3:0=0xffff'. Otherwise, you may not affect the whole cache. This likely means
that the cl_flush() function isn't the right abstraction for MPAM and the test needs a bit of
restructuring to get this to fit in elegantly. Similarly, to the limbo handler in resctrl you could
then check the llc_occupancy() to check it's under a "low enough" threshold.

Thanks,

Ben

> 
> Isn't this cl_flush() used without changing the resctrl control and monitor group (PARTID/PMG)?
> Hence, I expect you are ending up making the cache full of data associated with the identifiers that
> the benchmark runs with. Is that the case?
> 
> I'm also unclear how this the cat_test will detect any performance differences on arm/MPAM as the
> perf events would need to specific to the system level cache implementation.
> 
> Thanks,
> 
> Ben
> 
> 
> 
>>  }
>>  
> 

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Richard Cheng]

On Wed, Oct 21, 2026 at 10:55:35AM +0800, Ben Horgan wrote:
> Hi Richard,
> 
> On 20/10/2026 17:30, Ben Horgan wrote:
> > Hi Richard,
> > 
> > Thanks for having a look at the arm64 side of the resctrl selftests. That hasn't had much love but
> > it would be good to have them working properly.
> > 
> > On 12/10/2026 08:47, Richard Cheng wrote:
> >> cl_flush() and sb() compile to empty functions on aarch64, making
> >> mem_flush() a silent no-op and leaving CMT/CAT tests operating on
> >> unflushed state.
> >>
> >> Add "dsb sy" for sb(), ARM requires a DSB whose access type covers both
> >> loads and stores.
> > 
> > I guess this is referring to the synchronization required for the cache maintenance instruction but
> > that's not what you are using in this patch.
> > 
> >>
> >> For cl_flush(), "dc civac" only reaches the Point of Coherency, on
> >> ARM MPAM systems the SLC lies past the PoC and may be a NOP on coherent
> >> platforms. Instead, dirty each cacheline with a store so that
> >> mem_flush's full-buffer sweep evicts lines from the SLC via LRU
> >> pressure.
> >>
> >> Signed-off-by: Richard Cheng <icheng@nvidia.com>
> >> ---
> >>  tools/testing/selftests/resctrl/fill_buf.c | 11 +++++++++++
> >>  1 file changed, 11 insertions(+)
> >>
> >> diff --git a/tools/testing/selftests/resctrl/fill_buf.c b/tools/testing/selftests/resctrl/fill_buf.c
> >> index b9fa7968cd6e..eae0262fe265 100644
> >> --- a/tools/testing/selftests/resctrl/fill_buf.c
> >> +++ b/tools/testing/selftests/resctrl/fill_buf.c
> >> @@ -27,6 +27,9 @@ static void sb(void)
> >>  #if defined(__i386) || defined(__x86_64)
> >>  	asm volatile("sfence\n\t"
> >>  		     : : : "memory");
> >> +#elif defined(__aarch64__)
> >> +	asm volatile("dsb sy\n\t"
> >> +		     : : : "memory");
> >>  #endif
> >>  }
> >>  
> >> @@ -35,6 +38,14 @@ static void cl_flush(void *p)
> >>  #if defined(__i386) || defined(__x86_64)
> >>  	asm volatile("clflush (%0)\n\t"
> >>  		     : : "r"(p) : "memory");
> >> +#elif defined(__aarch64__)
> >> +	/*
> >> +	 * Dirty the cache line with a store. As mem_flush() sweeps
> >> +	 * the full test buffer (sized larger than the SLC), cache pressure
> >> +	 * evicts lines from the SLC via LRU replacement.
> >> +	 */
> >> +	asm volatile("strb wzr, [%0]\n\t"
> >> +		     : : "r"(p) : "memory");
> >>  #endif
> 
> One more thing that occurred to me is that if this is intended to evict all existing data in the
> cache then it would require that the cache portions bitmap for the control group (PARTID) in use is
> set to all 1s. E.g. 'L3:0=0xffff'. Otherwise, you may not affect the whole cache. This likely means
> that the cl_flush() function isn't the right abstraction for MPAM and the test needs a bit of
> restructuring to get this to fit in elegantly. Similarly, to the limbo handler in resctrl you could
> then check the llc_occupancy() to check it's under a "low enough" threshold.
> 
> Thanks,
> 
> Ben
>

Hi Ben,

Thanks for the feedback. I checked the code and ran some tests.
You're right, my implementation writes into the benchmark's own buffer using
the same PARRID/PMG, and the buffer isn't always larger than the SLC.

I can't claim that it produces an eviction sweep 100%.

I think what are want to do is to check whether reducing a group's cache
allocation causes more cache misses, thus the data left in cache from the
previous allocation must not affect the next measurement. That is also
why I want to reuse the concept of Intel's test with CLFLUSH before
warming the buffer under the new allocation.

I'm thinking maybe the assumption can't be achieve on ARM, I ran tests to
measure occupancy before and after each preparation method.

I tried this patch's implement, and "DC CIVAC" since I think it can affectively
invalidate cacheline without throwing old data away, which should left
occupancy almost unchanged.
And one more method with a separate large buffer in another group.

The result turns out like the following

Preparation                     Before (MiB)   After (MiB)
DC CIVAC + DSB SY                     51.19         50.47
zero-byte stores + DSB SY          53.12         56.43
Separate-buffer pressure             53.25          7.14


The current method increased the benchmark group's occupancy instead of
reducing it. "DC CIVAC" left occupancy almost unchanged.
The separate buffer method reduced occupancy very much, but still left data
behind.

It makes me think we should reconsider the test method. I think the goal is
to check whether the MPAM allocation limit works, clearing the cache is only
how the Intel RDT test prepares for that check.

How about we set a group's mask before its worker initialize the buffer and
then run sustained cache traffic and measure occupancy after it settles?
Maybe compare full, half and quarter masks to see whether the allocation limits take effect.

Does that sound like a useful direction for MPAM test for you ?

Best regards,
Richard Cheng.


 
> > 
> > Isn't this cl_flush() used without changing the resctrl control and monitor group (PARTID/PMG)?
> > Hence, I expect you are ending up making the cache full of data associated with the identifiers that
> > the benchmark runs with. Is that the case?
> > 
> > I'm also unclear how this the cat_test will detect any performance differences on arm/MPAM as the
> > perf events would need to specific to the system level cache implementation.
> > 
> > Thanks,
> > 
> > Ben
> > 
> > 
> > 
> >>  }
> >>  
> > 
> 

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Ben Horgan]

Hi Richard,

On 04/11/2026 06:43, Richard Cheng wrote:
> On Wed, Oct 21, 2026 at 10:55:35AM +0800, Ben Horgan wrote:
>> Hi Richard,
>>
>> On 20/10/2026 17:30, Ben Horgan wrote:
>>> Hi Richard,
>>>
>>> Thanks for having a look at the arm64 side of the resctrl selftests. That hasn't had much love but
>>> it would be good to have them working properly.
>>>
>>> On 12/10/2026 08:47, Richard Cheng wrote:
>>>> cl_flush() and sb() compile to empty functions on aarch64, making
>>>> mem_flush() a silent no-op and leaving CMT/CAT tests operating on
>>>> unflushed state.
>>>>
>>>> Add "dsb sy" for sb(), ARM requires a DSB whose access type covers both
>>>> loads and stores.
>>>
>>> I guess this is referring to the synchronization required for the cache maintenance instruction but
>>> that's not what you are using in this patch.
>>>
>>>>
>>>> For cl_flush(), "dc civac" only reaches the Point of Coherency, on
>>>> ARM MPAM systems the SLC lies past the PoC and may be a NOP on coherent
>>>> platforms. Instead, dirty each cacheline with a store so that
>>>> mem_flush's full-buffer sweep evicts lines from the SLC via LRU
>>>> pressure.
>>>>
>>>> Signed-off-by: Richard Cheng <icheng@nvidia.com>
>>>> ---
>>>>  tools/testing/selftests/resctrl/fill_buf.c | 11 +++++++++++
>>>>  1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/tools/testing/selftests/resctrl/fill_buf.c b/tools/testing/selftests/resctrl/fill_buf.c
>>>> index b9fa7968cd6e..eae0262fe265 100644
>>>> --- a/tools/testing/selftests/resctrl/fill_buf.c
>>>> +++ b/tools/testing/selftests/resctrl/fill_buf.c
>>>> @@ -27,6 +27,9 @@ static void sb(void)
>>>>  #if defined(__i386) || defined(__x86_64)
>>>>  	asm volatile("sfence\n\t"
>>>>  		     : : : "memory");
>>>> +#elif defined(__aarch64__)
>>>> +	asm volatile("dsb sy\n\t"
>>>> +		     : : : "memory");
>>>>  #endif
>>>>  }
>>>>  
>>>> @@ -35,6 +38,14 @@ static void cl_flush(void *p)
>>>>  #if defined(__i386) || defined(__x86_64)
>>>>  	asm volatile("clflush (%0)\n\t"
>>>>  		     : : "r"(p) : "memory");
>>>> +#elif defined(__aarch64__)
>>>> +	/*
>>>> +	 * Dirty the cache line with a store. As mem_flush() sweeps
>>>> +	 * the full test buffer (sized larger than the SLC), cache pressure
>>>> +	 * evicts lines from the SLC via LRU replacement.
>>>> +	 */
>>>> +	asm volatile("strb wzr, [%0]\n\t"
>>>> +		     : : "r"(p) : "memory");
>>>>  #endif
>>
>> One more thing that occurred to me is that if this is intended to evict all existing data in the
>> cache then it would require that the cache portions bitmap for the control group (PARTID) in use is
>> set to all 1s. E.g. 'L3:0=0xffff'. Otherwise, you may not affect the whole cache. This likely means
>> that the cl_flush() function isn't the right abstraction for MPAM and the test needs a bit of
>> restructuring to get this to fit in elegantly. Similarly, to the limbo handler in resctrl you could
>> then check the llc_occupancy() to check it's under a "low enough" threshold.
>>
>> Thanks,
>>
>> Ben
>>
> 
> Hi Ben,
> 
> Thanks for the feedback. I checked the code and ran some tests.
> You're right, my implementation writes into the benchmark's own buffer using
> the same PARRID/PMG, and the buffer isn't always larger than the SLC.
> 
> I can't claim that it produces an eviction sweep 100%.
> 
> I think what are want to do is to check whether reducing a group's cache
> allocation causes more cache misses, thus the data left in cache from the
> previous allocation must not affect the next measurement. That is also
> why I want to reuse the concept of Intel's test with CLFLUSH before
> warming the buffer under the new allocation.
> 
> I'm thinking maybe the assumption can't be achieve on ARM, I ran tests to
> measure occupancy before and after each preparation method.
> 
> I tried this patch's implement, and "DC CIVAC" since I think it can affectively
> invalidate cacheline without throwing old data away, which should left
> occupancy almost unchanged.
> And one more method with a separate large buffer in another group.
> 
> The result turns out like the following
> 
> Preparation                     Before (MiB)   After (MiB)
> DC CIVAC + DSB SY                     51.19         50.47
> zero-byte stores + DSB SY          53.12         56.43
> Separate-buffer pressure             53.25          7.14
> 
> 
> The current method increased the benchmark group's occupancy instead of
> reducing it. "DC CIVAC" left occupancy almost unchanged.
> The separate buffer method reduced occupancy very much, but still left data
> behind.
> 
> It makes me think we should reconsider the test method. I think the goal is
> to check whether the MPAM allocation limit works, clearing the cache is only
> how the Intel RDT test prepares for that check.
> 
> How about we set a group's mask before its worker initialize the buffer and

We'll still need to make sure that the PARTID used for the test hasn't got high occupancy in the
cache before running the benchmark.

> then run sustained cache traffic and measure occupancy after it settles?

I assume the occupancy is measured via resctrl, llc_occupancy.

> Maybe compare full, half and quarter masks to see whether the allocation limits take effect.
> 
> Does that sound like a useful direction for MPAM test for you ?

Yes, I think so.

Would it end up like this?

1. Choose a test control group and ensure that it doesn't have high cache occupancy using llc_occupancy
(If it does have high cache occupancy then clean it. Probably by using separate buffer with a
separate control group)
2. Configure the L3 cache bitmap for the test control group
3. Run a benchmark
4. Check that the llc_occupancy is as expected
5. Repeat 1-4 with different cache bitmaps.

However, it doesn't sound specific to MPAM but more like a general test for the cache portion
bitmap. Possibly it can be a separate cross-architecture resctrl selftest that compliments the
(somewhat) intel specific cat_test. (There isn't a platform independent way of measuring slc cache
misses on arm64.) This depends of the resctrl selftest maintainers view.

Thanks,

Ben

> 
> Best regards,
> Richard Cheng.
> 
> 
>  
>>>
>>> Isn't this cl_flush() used without changing the resctrl control and monitor group (PARTID/PMG)?
>>> Hence, I expect you are ending up making the cache full of data associated with the identifiers that
>>> the benchmark runs with. Is that the case?
>>>
>>> I'm also unclear how this the cat_test will detect any performance differences on arm/MPAM as the
>>> perf events would need to specific to the system level cache implementation.
>>>
>>> Thanks,
>>>
>>> Ben
>>>
>>>
>>>
>>>>  }
>>>>  
>>>
>>

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Richard Cheng]

On Wed, Nov 04, 2026 at 05:09:28PM +0800, Ben Horgan wrote:
> Hi Richard,
> 
> On 04/11/2026 06:43, Richard Cheng wrote:
> > On Wed, Oct 21, 2026 at 10:55:35AM +0800, Ben Horgan wrote:
> >> Hi Richard,
> >>
> >> On 20/10/2026 17:30, Ben Horgan wrote:
> >>> Hi Richard,
> >>>
> >>> Thanks for having a look at the arm64 side of the resctrl selftests. That hasn't had much love but
> >>> it would be good to have them working properly.
> >>>
> >>> On 12/10/2026 08:47, Richard Cheng wrote:
> >>>> cl_flush() and sb() compile to empty functions on aarch64, making
> >>>> mem_flush() a silent no-op and leaving CMT/CAT tests operating on
> >>>> unflushed state.
> >>>>
> >>>> Add "dsb sy" for sb(), ARM requires a DSB whose access type covers both
> >>>> loads and stores.
> >>>
> >>> I guess this is referring to the synchronization required for the cache maintenance instruction but
> >>> that's not what you are using in this patch.
> >>>
> >>>>
> >>>> For cl_flush(), "dc civac" only reaches the Point of Coherency, on
> >>>> ARM MPAM systems the SLC lies past the PoC and may be a NOP on coherent
> >>>> platforms. Instead, dirty each cacheline with a store so that
> >>>> mem_flush's full-buffer sweep evicts lines from the SLC via LRU
> >>>> pressure.
> >>>>
> >>>> Signed-off-by: Richard Cheng <icheng@nvidia.com>
> >>>> ---
> >>>>  tools/testing/selftests/resctrl/fill_buf.c | 11 +++++++++++
> >>>>  1 file changed, 11 insertions(+)
> >>>>
> >>>> diff --git a/tools/testing/selftests/resctrl/fill_buf.c b/tools/testing/selftests/resctrl/fill_buf.c
> >>>> index b9fa7968cd6e..eae0262fe265 100644
> >>>> --- a/tools/testing/selftests/resctrl/fill_buf.c
> >>>> +++ b/tools/testing/selftests/resctrl/fill_buf.c
> >>>> @@ -27,6 +27,9 @@ static void sb(void)
> >>>>  #if defined(__i386) || defined(__x86_64)
> >>>>  	asm volatile("sfence\n\t"
> >>>>  		     : : : "memory");
> >>>> +#elif defined(__aarch64__)
> >>>> +	asm volatile("dsb sy\n\t"
> >>>> +		     : : : "memory");
> >>>>  #endif
> >>>>  }
> >>>>  
> >>>> @@ -35,6 +38,14 @@ static void cl_flush(void *p)
> >>>>  #if defined(__i386) || defined(__x86_64)
> >>>>  	asm volatile("clflush (%0)\n\t"
> >>>>  		     : : "r"(p) : "memory");
> >>>> +#elif defined(__aarch64__)
> >>>> +	/*
> >>>> +	 * Dirty the cache line with a store. As mem_flush() sweeps
> >>>> +	 * the full test buffer (sized larger than the SLC), cache pressure
> >>>> +	 * evicts lines from the SLC via LRU replacement.
> >>>> +	 */
> >>>> +	asm volatile("strb wzr, [%0]\n\t"
> >>>> +		     : : "r"(p) : "memory");
> >>>>  #endif
> >>
> >> One more thing that occurred to me is that if this is intended to evict all existing data in the
> >> cache then it would require that the cache portions bitmap for the control group (PARTID) in use is
> >> set to all 1s. E.g. 'L3:0=0xffff'. Otherwise, you may not affect the whole cache. This likely means
> >> that the cl_flush() function isn't the right abstraction for MPAM and the test needs a bit of
> >> restructuring to get this to fit in elegantly. Similarly, to the limbo handler in resctrl you could
> >> then check the llc_occupancy() to check it's under a "low enough" threshold.
> >>
> >> Thanks,
> >>
> >> Ben
> >>
> > 
> > Hi Ben,
> > 
> > Thanks for the feedback. I checked the code and ran some tests.
> > You're right, my implementation writes into the benchmark's own buffer using
> > the same PARRID/PMG, and the buffer isn't always larger than the SLC.
> > 
> > I can't claim that it produces an eviction sweep 100%.
> > 
> > I think what are want to do is to check whether reducing a group's cache
> > allocation causes more cache misses, thus the data left in cache from the
> > previous allocation must not affect the next measurement. That is also
> > why I want to reuse the concept of Intel's test with CLFLUSH before
> > warming the buffer under the new allocation.
> > 
> > I'm thinking maybe the assumption can't be achieve on ARM, I ran tests to
> > measure occupancy before and after each preparation method.
> > 
> > I tried this patch's implement, and "DC CIVAC" since I think it can affectively
> > invalidate cacheline without throwing old data away, which should left
> > occupancy almost unchanged.
> > And one more method with a separate large buffer in another group.
> > 
> > The result turns out like the following
> > 
> > Preparation                     Before (MiB)   After (MiB)
> > DC CIVAC + DSB SY                     51.19         50.47
> > zero-byte stores + DSB SY          53.12         56.43
> > Separate-buffer pressure             53.25          7.14
> > 
> > 
> > The current method increased the benchmark group's occupancy instead of
> > reducing it. "DC CIVAC" left occupancy almost unchanged.
> > The separate buffer method reduced occupancy very much, but still left data
> > behind.
> > 
> > It makes me think we should reconsider the test method. I think the goal is
> > to check whether the MPAM allocation limit works, clearing the cache is only
> > how the Intel RDT test prepares for that check.
> > 
> > How about we set a group's mask before its worker initialize the buffer and
> 
> We'll still need to make sure that the PARTID used for the test hasn't got high occupancy in the
> cache before running the benchmark.
> 
> > then run sustained cache traffic and measure occupancy after it settles?
> 
> I assume the occupancy is measured via resctrl, llc_occupancy.
> 
> > Maybe compare full, half and quarter masks to see whether the allocation limits take effect.
> > 
> > Does that sound like a useful direction for MPAM test for you ?
> 
> Yes, I think so.
> 
> Would it end up like this?
> 
> 1. Choose a test control group and ensure that it doesn't have high cache occupancy using llc_occupancy
> (If it does have high cache occupancy then clean it. Probably by using separate buffer with a
> separate control group)
> 2. Configure the L3 cache bitmap for the test control group
> 3. Run a benchmark
> 4. Check that the llc_occupancy is as expected
> 5. Repeat 1-4 with different cache bitmaps.
> 
> However, it doesn't sound specific to MPAM but more like a general test for the cache portion
> bitmap. Possibly it can be a separate cross-architecture resctrl selftest that compliments the
> (somewhat) intel specific cat_test. (There isn't a platform independent way of measuring slc cache
> misses on arm64.) This depends of the resctrl selftest maintainers view.
> 
> Thanks,
> 
> Ben
>

Hi Ben,
I like the idea to make it a general test for cache on different arch,
but yeah let's leave it for resctrl's maintainers to decide, I do not know other
arch's cache topology and such so what I'm designing is very likely to overfit on ARM64.

Anyway, per your suggestion, I tried a few experiment and came up with the approach
like the following, and still have some points needs to discuss with you if you don't mind.

We'll reuse one test group and buffer across tests for different bitmaps,
and a separate group and buffer for sweeping.

1. Set up. Create the test and sweep group, assign workers, init buffer, give the sweep group the full cache mask.
2. Prepare before each mask. Keep the test worker stopped. Run the sweep worker and check "llc_occupancy" repeately,
until it stays below a starting threshold, I set it as 4KB on my testing machine, we can discuss about it
since the value should fit on different machine. And we'll put a timeout for cleanup time.
3. Stop the sweep and apply cache maskWarmup test workload for 3 sec
4. Run the workloadRead llc_occupancy and see if it meets the expected value ( that's what we need to discuss )

So on my machine it has a 164 MB share cache, no matter what cache masks I use, the cache occupancy won't be 100%,
even I use some mask like 0001, 8000. I'm not sure what kind of expectation should we apply on the test,
just not exceeding the rule's enforcement is enough ? or should it exceed certain amount of usage ?
And for the sweep method, even sweep like 100 times with another buffer, we can't gaurantee to evict all of the old data from the cache,
so I came up with another idea that everytime we make a new test, we use a new buffer and a new test group,
leaving old data in the old group.

However, sometimes non-zero reading still occurs, and it might happen more frequently on smaller machine,
so I think your proposed sweeping approach is better.

I hope this is getting closer to a desired design before I implement v6.

Best regards,
Richard Cheng.




 
> > 
> > Best regards,
> > Richard Cheng.
> > 
> > 
> >  
> >>>
> >>> Isn't this cl_flush() used without changing the resctrl control and monitor group (PARTID/PMG)?
> >>> Hence, I expect you are ending up making the cache full of data associated with the identifiers that
> >>> the benchmark runs with. Is that the case?
> >>>
> >>> I'm also unclear how this the cat_test will detect any performance differences on arm/MPAM as the
> >>> perf events would need to specific to the system level cache implementation.
> >>>
> >>> Thanks,
> >>>
> >>> Ben
> >>>
> >>>
> >>>
> >>>>  }
> >>>>  
> >>>
> >>
> 

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Ben Horgan]

Hi Richard,

On 05/11/2026 09:41, Richard Cheng wrote:
> On Wed, Nov 04, 2026 at 05:09:28PM +0800, Ben Horgan wrote:
>> Hi Richard,
>>
>> On 04/11/2026 06:43, Richard Cheng wrote:
>>> On Wed, Oct 21, 2026 at 10:55:35AM +0800, Ben Horgan wrote:
>>>> Hi Richard,
>>>>
>>>> On 20/10/2026 17:30, Ben Horgan wrote:
>>>>> Hi Richard,
>>>>>
>>>>> Thanks for having a look at the arm64 side of the resctrl selftests. That hasn't had much love but
>>>>> it would be good to have them working properly.
>>>>>
>>>>> On 12/10/2026 08:47, Richard Cheng wrote:
>>>>>> cl_flush() and sb() compile to empty functions on aarch64, making
>>>>>> mem_flush() a silent no-op and leaving CMT/CAT tests operating on
>>>>>> unflushed state.
>>>>>>
>>>>>> Add "dsb sy" for sb(), ARM requires a DSB whose access type covers both
>>>>>> loads and stores.
>>>>>
>>>>> I guess this is referring to the synchronization required for the cache maintenance instruction but
>>>>> that's not what you are using in this patch.
>>>>>
>>>>>>
>>>>>> For cl_flush(), "dc civac" only reaches the Point of Coherency, on
>>>>>> ARM MPAM systems the SLC lies past the PoC and may be a NOP on coherent
>>>>>> platforms. Instead, dirty each cacheline with a store so that
>>>>>> mem_flush's full-buffer sweep evicts lines from the SLC via LRU
>>>>>> pressure.
>>>>>>
>>>>>> Signed-off-by: Richard Cheng <icheng@nvidia.com>
>>>>>> ---
>>>>>>  tools/testing/selftests/resctrl/fill_buf.c | 11 +++++++++++
>>>>>>  1 file changed, 11 insertions(+)
>>>>>>
>>>>>> diff --git a/tools/testing/selftests/resctrl/fill_buf.c b/tools/testing/selftests/resctrl/fill_buf.c
>>>>>> index b9fa7968cd6e..eae0262fe265 100644
>>>>>> --- a/tools/testing/selftests/resctrl/fill_buf.c
>>>>>> +++ b/tools/testing/selftests/resctrl/fill_buf.c
>>>>>> @@ -27,6 +27,9 @@ static void sb(void)
>>>>>>  #if defined(__i386) || defined(__x86_64)
>>>>>>  	asm volatile("sfence\n\t"
>>>>>>  		     : : : "memory");
>>>>>> +#elif defined(__aarch64__)
>>>>>> +	asm volatile("dsb sy\n\t"
>>>>>> +		     : : : "memory");
>>>>>>  #endif
>>>>>>  }
>>>>>>  
>>>>>> @@ -35,6 +38,14 @@ static void cl_flush(void *p)
>>>>>>  #if defined(__i386) || defined(__x86_64)
>>>>>>  	asm volatile("clflush (%0)\n\t"
>>>>>>  		     : : "r"(p) : "memory");
>>>>>> +#elif defined(__aarch64__)
>>>>>> +	/*
>>>>>> +	 * Dirty the cache line with a store. As mem_flush() sweeps
>>>>>> +	 * the full test buffer (sized larger than the SLC), cache pressure
>>>>>> +	 * evicts lines from the SLC via LRU replacement.
>>>>>> +	 */
>>>>>> +	asm volatile("strb wzr, [%0]\n\t"
>>>>>> +		     : : "r"(p) : "memory");
>>>>>>  #endif
>>>>
>>>> One more thing that occurred to me is that if this is intended to evict all existing data in the
>>>> cache then it would require that the cache portions bitmap for the control group (PARTID) in use is
>>>> set to all 1s. E.g. 'L3:0=0xffff'. Otherwise, you may not affect the whole cache. This likely means
>>>> that the cl_flush() function isn't the right abstraction for MPAM and the test needs a bit of
>>>> restructuring to get this to fit in elegantly. Similarly, to the limbo handler in resctrl you could
>>>> then check the llc_occupancy() to check it's under a "low enough" threshold.
>>>>
>>>> Thanks,
>>>>
>>>> Ben
>>>>
>>>
>>> Hi Ben,
>>>
>>> Thanks for the feedback. I checked the code and ran some tests.
>>> You're right, my implementation writes into the benchmark's own buffer using
>>> the same PARRID/PMG, and the buffer isn't always larger than the SLC.
>>>
>>> I can't claim that it produces an eviction sweep 100%.
>>>
>>> I think what are want to do is to check whether reducing a group's cache
>>> allocation causes more cache misses, thus the data left in cache from the
>>> previous allocation must not affect the next measurement. That is also
>>> why I want to reuse the concept of Intel's test with CLFLUSH before
>>> warming the buffer under the new allocation.
>>>
>>> I'm thinking maybe the assumption can't be achieve on ARM, I ran tests to
>>> measure occupancy before and after each preparation method.
>>>
>>> I tried this patch's implement, and "DC CIVAC" since I think it can affectively
>>> invalidate cacheline without throwing old data away, which should left
>>> occupancy almost unchanged.
>>> And one more method with a separate large buffer in another group.
>>>
>>> The result turns out like the following
>>>
>>> Preparation                     Before (MiB)   After (MiB)
>>> DC CIVAC + DSB SY                     51.19         50.47
>>> zero-byte stores + DSB SY          53.12         56.43
>>> Separate-buffer pressure             53.25          7.14
>>>
>>>
>>> The current method increased the benchmark group's occupancy instead of
>>> reducing it. "DC CIVAC" left occupancy almost unchanged.
>>> The separate buffer method reduced occupancy very much, but still left data
>>> behind.
>>>
>>> It makes me think we should reconsider the test method. I think the goal is
>>> to check whether the MPAM allocation limit works, clearing the cache is only
>>> how the Intel RDT test prepares for that check.
>>>
>>> How about we set a group's mask before its worker initialize the buffer and
>>
>> We'll still need to make sure that the PARTID used for the test hasn't got high occupancy in the
>> cache before running the benchmark.
>>
>>> then run sustained cache traffic and measure occupancy after it settles?
>>
>> I assume the occupancy is measured via resctrl, llc_occupancy.
>>
>>> Maybe compare full, half and quarter masks to see whether the allocation limits take effect.
>>>
>>> Does that sound like a useful direction for MPAM test for you ?
>>
>> Yes, I think so.
>>
>> Would it end up like this?
>>
>> 1. Choose a test control group and ensure that it doesn't have high cache occupancy using llc_occupancy
>> (If it does have high cache occupancy then clean it. Probably by using separate buffer with a
>> separate control group)
>> 2. Configure the L3 cache bitmap for the test control group
>> 3. Run a benchmark
>> 4. Check that the llc_occupancy is as expected
>> 5. Repeat 1-4 with different cache bitmaps.
>>
>> However, it doesn't sound specific to MPAM but more like a general test for the cache portion
>> bitmap. Possibly it can be a separate cross-architecture resctrl selftest that compliments the
>> (somewhat) intel specific cat_test. (There isn't a platform independent way of measuring slc cache
>> misses on arm64.) This depends of the resctrl selftest maintainers view.
>>
>> Thanks,
>>
>> Ben
>>
> 
> Hi Ben,
> I like the idea to make it a general test for cache on different arch,
> but yeah let's leave it for resctrl's maintainers to decide, I do not know other
> arch's cache topology and such so what I'm designing is very likely to overfit on ARM64.
> 
> Anyway, per your suggestion, I tried a few experiment and came up with the approach
> like the following, and still have some points needs to discuss with you if you don't mind.
> 
> We'll reuse one test group and buffer across tests for different bitmaps,
> and a separate group and buffer for sweeping.
> 
> 1. Set up. Create the test and sweep group, assign workers, init buffer, give the sweep group the full cache mask.
> 2. Prepare before each mask. Keep the test worker stopped. Run the sweep worker and check "llc_occupancy" repeately,
> until it stays below a starting threshold, I set it as 4KB on my testing machine, we can discuss about it

A starting threshold of 4KB on a machine with 164MB cache seems lower than required. Assuming, the
maximum number of cache portions supported by resctrl, 32, then each portion is about 5MB, and so if
you are measuring occupancy to check if the cache portion bitmap has the desired effect then 4KB is
in the noise.

> since the value should fit on different machine. And we'll put a timeout for cleanup time.
> 3. Stop the sweep and apply cache maskWarmup test workload for 3 sec
> 4. Run the workloadRead llc_occupancy and see if it meets the expected value ( that's what we need to discuss )
> 
> So on my machine it has a 164 MB share cache, no matter what cache masks I use, the cache occupancy won't be 100%,
> even I use some mask like 0001, 8000. I'm not sure what kind of expectation should we apply on the test,
> just not exceeding the rule's enforcement is enough ? or should it exceed certain amount of usage ?


I'd say just sufficient precision to be able distinguish between a cache bitmap with n bit set and
one with n + 1 bits.

Does checking which of these intervals the occupancy in give you a reproducible way of determining
how many bits are set? Hopefully overshoot can be sized to make this reliable.

(0, size/num_bits + overshoot),
(size/num_bits + overshoot, 2*size/num_bits + overshoot),
(2*size/num_bits + overshoot, 3*size/num_bits + overshoot),
...
((num_bits - 1)*size/num_bits + overshoot, size)

As you mention above, making this reliable across architectures and even across arm platforms means
that you can't be just be looking for precise numbers or exactly repeatable behaviour.

Thanks,

Ben

> And for the sweep method, even sweep like 100 times with another buffer, we can't gaurantee to evict all of the old data from the cache,
> so I came up with another idea that everytime we make a new test, we use a new buffer and a new test group,
> leaving old data in the old group.
> 
> However, sometimes non-zero reading still occurs, and it might happen more frequently on smaller machine,
> so I think your proposed sweeping approach is better.
> 
> I hope this is getting closer to a desired design before I implement v6.
> 
> Best regards,
> Richard Cheng.
> 
> 
> 
> 
>  
>>>
>>> Best regards,
>>> Richard Cheng.
>>>
>>>
>>>  
>>>>>
>>>>> Isn't this cl_flush() used without changing the resctrl control and monitor group (PARTID/PMG)?
>>>>> Hence, I expect you are ending up making the cache full of data associated with the identifiers that
>>>>> the benchmark runs with. Is that the case?
>>>>>
>>>>> I'm also unclear how this the cat_test will detect any performance differences on arm/MPAM as the
>>>>> perf events would need to specific to the system level cache implementation.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>>>  }
>>>>>>  
>>>>>
>>>>
>>

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Reinette Chatre]

Hi Ben and Richard,

On 11/6/26 7:53 AM, Ben Horgan wrote:
> Hi Richard,
> 
> On 05/11/2026 09:41, Richard Cheng wrote:
>> On Wed, Nov 04, 2026 at 05:09:28PM +0800, Ben Horgan wrote:
>>> Hi Richard,
>>>
>>> On 04/11/2026 06:43, Richard Cheng wrote:
>>>> On Wed, Oct 21, 2026 at 10:55:35AM +0800, Ben Horgan wrote:
>>>>> Hi Richard,
>>>>>
>>>>> On 20/10/2026 17:30, Ben Horgan wrote:
>>>>>> Hi Richard,
>>>>>>
>>>>>> Thanks for having a look at the arm64 side of the resctrl selftests. That hasn't had much love but
>>>>>> it would be good to have them working properly.
>>>>>>
>>>>>> On 12/10/2026 08:47, Richard Cheng wrote:
>>>>>>> cl_flush() and sb() compile to empty functions on aarch64, making
>>>>>>> mem_flush() a silent no-op and leaving CMT/CAT tests operating on
>>>>>>> unflushed state.
>>>>>>>
>>>>>>> Add "dsb sy" for sb(), ARM requires a DSB whose access type covers both
>>>>>>> loads and stores.
>>>>>>
>>>>>> I guess this is referring to the synchronization required for the cache maintenance instruction but
>>>>>> that's not what you are using in this patch.
>>>>>>
>>>>>>>
>>>>>>> For cl_flush(), "dc civac" only reaches the Point of Coherency, on
>>>>>>> ARM MPAM systems the SLC lies past the PoC and may be a NOP on coherent
>>>>>>> platforms. Instead, dirty each cacheline with a store so that
>>>>>>> mem_flush's full-buffer sweep evicts lines from the SLC via LRU
>>>>>>> pressure.
>>>>>>>
>>>>>>> Signed-off-by: Richard Cheng <icheng@nvidia.com>
>>>>>>> ---
>>>>>>>  tools/testing/selftests/resctrl/fill_buf.c | 11 +++++++++++
>>>>>>>  1 file changed, 11 insertions(+)
>>>>>>>
>>>>>>> diff --git a/tools/testing/selftests/resctrl/fill_buf.c b/tools/testing/selftests/resctrl/fill_buf.c
>>>>>>> index b9fa7968cd6e..eae0262fe265 100644
>>>>>>> --- a/tools/testing/selftests/resctrl/fill_buf.c
>>>>>>> +++ b/tools/testing/selftests/resctrl/fill_buf.c
>>>>>>> @@ -27,6 +27,9 @@ static void sb(void)
>>>>>>>  #if defined(__i386) || defined(__x86_64)
>>>>>>>  	asm volatile("sfence\n\t"
>>>>>>>  		     : : : "memory");
>>>>>>> +#elif defined(__aarch64__)
>>>>>>> +	asm volatile("dsb sy\n\t"
>>>>>>> +		     : : : "memory");
>>>>>>>  #endif
>>>>>>>  }
>>>>>>>  
>>>>>>> @@ -35,6 +38,14 @@ static void cl_flush(void *p)
>>>>>>>  #if defined(__i386) || defined(__x86_64)
>>>>>>>  	asm volatile("clflush (%0)\n\t"
>>>>>>>  		     : : "r"(p) : "memory");
>>>>>>> +#elif defined(__aarch64__)
>>>>>>> +	/*
>>>>>>> +	 * Dirty the cache line with a store. As mem_flush() sweeps
>>>>>>> +	 * the full test buffer (sized larger than the SLC), cache pressure
>>>>>>> +	 * evicts lines from the SLC via LRU replacement.
>>>>>>> +	 */
>>>>>>> +	asm volatile("strb wzr, [%0]\n\t"
>>>>>>> +		     : : "r"(p) : "memory");
>>>>>>>  #endif
>>>>>
>>>>> One more thing that occurred to me is that if this is intended to evict all existing data in the
>>>>> cache then it would require that the cache portions bitmap for the control group (PARTID) in use is
>>>>> set to all 1s. E.g. 'L3:0=0xffff'. Otherwise, you may not affect the whole cache. This likely means
>>>>> that the cl_flush() function isn't the right abstraction for MPAM and the test needs a bit of
>>>>> restructuring to get this to fit in elegantly. Similarly, to the limbo handler in resctrl you could
>>>>> then check the llc_occupancy() to check it's under a "low enough" threshold.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ben
>>>>>
>>>>
>>>> Hi Ben,
>>>>
>>>> Thanks for the feedback. I checked the code and ran some tests.
>>>> You're right, my implementation writes into the benchmark's own buffer using
>>>> the same PARRID/PMG, and the buffer isn't always larger than the SLC.
>>>>
>>>> I can't claim that it produces an eviction sweep 100%.
>>>>
>>>> I think what are want to do is to check whether reducing a group's cache
>>>> allocation causes more cache misses, thus the data left in cache from the
>>>> previous allocation must not affect the next measurement. That is also
>>>> why I want to reuse the concept of Intel's test with CLFLUSH before
>>>> warming the buffer under the new allocation.
>>>>
>>>> I'm thinking maybe the assumption can't be achieve on ARM, I ran tests to
>>>> measure occupancy before and after each preparation method.
>>>>
>>>> I tried this patch's implement, and "DC CIVAC" since I think it can affectively
>>>> invalidate cacheline without throwing old data away, which should left
>>>> occupancy almost unchanged.
>>>> And one more method with a separate large buffer in another group.
>>>>
>>>> The result turns out like the following
>>>>
>>>> Preparation                     Before (MiB)   After (MiB)
>>>> DC CIVAC + DSB SY                     51.19         50.47
>>>> zero-byte stores + DSB SY          53.12         56.43
>>>> Separate-buffer pressure             53.25          7.14
>>>>
>>>>
>>>> The current method increased the benchmark group's occupancy instead of
>>>> reducing it. "DC CIVAC" left occupancy almost unchanged.
>>>> The separate buffer method reduced occupancy very much, but still left data
>>>> behind.
>>>>
>>>> It makes me think we should reconsider the test method. I think the goal is
>>>> to check whether the MPAM allocation limit works, clearing the cache is only
>>>> how the Intel RDT test prepares for that check.
>>>>
>>>> How about we set a group's mask before its worker initialize the buffer and
>>>
>>> We'll still need to make sure that the PARTID used for the test hasn't got high occupancy in the
>>> cache before running the benchmark.
>>>
>>>> then run sustained cache traffic and measure occupancy after it settles?
>>>
>>> I assume the occupancy is measured via resctrl, llc_occupancy.
>>>
>>>> Maybe compare full, half and quarter masks to see whether the allocation limits take effect.
>>>>
>>>> Does that sound like a useful direction for MPAM test for you ?
>>>
>>> Yes, I think so.
>>>
>>> Would it end up like this?
>>>
>>> 1. Choose a test control group and ensure that it doesn't have high cache occupancy using llc_occupancy
>>> (If it does have high cache occupancy then clean it. Probably by using separate buffer with a
>>> separate control group)
>>> 2. Configure the L3 cache bitmap for the test control group
>>> 3. Run a benchmark
>>> 4. Check that the llc_occupancy is as expected
>>> 5. Repeat 1-4 with different cache bitmaps.
>>>
>>> However, it doesn't sound specific to MPAM but more like a general test for the cache portion
>>> bitmap. Possibly it can be a separate cross-architecture resctrl selftest that compliments the
>>> (somewhat) intel specific cat_test. (There isn't a platform independent way of measuring slc cache
>>> misses on arm64.) This depends of the resctrl selftest maintainers view.
>>>
>>> Thanks,
>>>
>>> Ben
>>>
>>
>> Hi Ben,
>> I like the idea to make it a general test for cache on different arch,
>> but yeah let's leave it for resctrl's maintainers to decide, I do not know other
>> arch's cache topology and such so what I'm designing is very likely to overfit on ARM64.
>>
>> Anyway, per your suggestion, I tried a few experiment and came up with the approach
>> like the following, and still have some points needs to discuss with you if you don't mind.
>>
>> We'll reuse one test group and buffer across tests for different bitmaps,
>> and a separate group and buffer for sweeping.
>>
>> 1. Set up. Create the test and sweep group, assign workers, init buffer, give the sweep group the full cache mask.
>> 2. Prepare before each mask. Keep the test worker stopped. Run the sweep worker and check "llc_occupancy" repeately,
>> until it stays below a starting threshold, I set it as 4KB on my testing machine, we can discuss about it
> 
> A starting threshold of 4KB on a machine with 164MB cache seems lower than required. Assuming, the
> maximum number of cache portions supported by resctrl, 32, then each portion is about 5MB, and so if
> you are measuring occupancy to check if the cache portion bitmap has the desired effect then 4KB is
> in the noise.
> 
>> since the value should fit on different machine. And we'll put a timeout for cleanup time.
>> 3. Stop the sweep and apply cache maskWarmup test workload for 3 sec
>> 4. Run the workloadRead llc_occupancy and see if it meets the expected value ( that's what we need to discuss )
>>
>> So on my machine it has a 164 MB share cache, no matter what cache masks I use, the cache occupancy won't be 100%,
>> even I use some mask like 0001, 8000. I'm not sure what kind of expectation should we apply on the test,
>> just not exceeding the rule's enforcement is enough ? or should it exceed certain amount of usage ?
> 
> 
> I'd say just sufficient precision to be able distinguish between a cache bitmap with n bit set and
> one with n + 1 bits.
> 
> Does checking which of these intervals the occupancy in give you a reproducible way of determining
> how many bits are set? Hopefully overshoot can be sized to make this reliable.
> 
> (0, size/num_bits + overshoot),
> (size/num_bits + overshoot, 2*size/num_bits + overshoot),
> (2*size/num_bits + overshoot, 3*size/num_bits + overshoot),
> ...
> ((num_bits - 1)*size/num_bits + overshoot, size)
> 
> As you mention above, making this reliable across architectures and even across arm platforms means
> that you can't be just be looking for precise numbers or exactly repeatable behaviour.
> 
Using benchmarks as a measure of resctrl health keeps giving problems due to the differences
between systems. I cannot recall these tests failing because of an issue in resctrl self, which
they are intended to test, yet they do fail and then need to be "tweaked" to accommodate some
new architectural nuance that has nothing to do with the resctrl subsystem. For example,

	https://lore.kernel.org/all/6de4da5486354c0f25fef0d194956470cb744041.1775266384.git.reinette.chatre@intel.com/

Please take a moment and consider what you want to achieve with these tests: what is this
intended to test? In a way the benchmarks seem to be testing the hardware capabilities and useful
to hardware validation folks more so than testing resctrl subsystem in a useful way to
kernel development. 

More specifically, if this test "fails" - is there *anything* we can do about
it that does not involve "fixing" the test? 

In the end I find these performance tests valuable in how they interact with the
resctrl filesystem in different ways, not the actual performance values returned by the tests.

Of course it is up to you, I am just concerned that you may end up (as I have) spending a lot
of effort on work that does not end up being a deterministic measurement of resctrl health yet
is used to produce a "pass" or "fail" verdict about resctrl subsystem health.

If you do end up using a benchmark I'd suggest to make the checks as forgiving as
possible. For example, instead of checking something like "LLC occupancy needs to be
X when bitmap is Y" it should check something like "LLC occupancy when bitmap is all ones
is larger than LLC occupancy when only half of bitmap is ones". 

I find work like

	https://lore.kernel.org/all/20260810095124.32244-1-icheng@nvidia.com/

to be valuable as deterministic measurements of resctrl health.

Reinette

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Ben Horgan]

Hi Reinette and Richard,

On 07/11/2026 00:29, Reinette Chatre wrote:
> Hi Ben and Richard,
> 
> On 11/6/26 7:53 AM, Ben Horgan wrote:
>> Hi Richard,
>>
>> On 05/11/2026 09:41, Richard Cheng wrote:
>>> On Wed, Nov 04, 2026 at 05:09:28PM +0800, Ben Horgan wrote:
>>>> Hi Richard,
>>>>
>>>> On 04/11/2026 06:43, Richard Cheng wrote:
>>>>> On Wed, Oct 21, 2026 at 10:55:35AM +0800, Ben Horgan wrote:
>>>>>> Hi Richard,
>>>>>>
>>>>>> On 20/10/2026 17:30, Ben Horgan wrote:
>>>>>>> Hi Richard,
>>>>>>>
>>>>>>> Thanks for having a look at the arm64 side of the resctrl selftests. That hasn't had much love but
>>>>>>> it would be good to have them working properly.
>>>>>>>
>>>>>>> On 12/10/2026 08:47, Richard Cheng wrote:
>>>>>>>> cl_flush() and sb() compile to empty functions on aarch64, making
>>>>>>>> mem_flush() a silent no-op and leaving CMT/CAT tests operating on
>>>>>>>> unflushed state.
>>>>>>>>
>>>>>>>> Add "dsb sy" for sb(), ARM requires a DSB whose access type covers both
>>>>>>>> loads and stores.
>>>>>>>
>>>>>>> I guess this is referring to the synchronization required for the cache maintenance instruction but
>>>>>>> that's not what you are using in this patch.
>>>>>>>
>>>>>>>>
>>>>>>>> For cl_flush(), "dc civac" only reaches the Point of Coherency, on
>>>>>>>> ARM MPAM systems the SLC lies past the PoC and may be a NOP on coherent
>>>>>>>> platforms. Instead, dirty each cacheline with a store so that
>>>>>>>> mem_flush's full-buffer sweep evicts lines from the SLC via LRU
>>>>>>>> pressure.
>>>>>>>>
>>>>>>>> Signed-off-by: Richard Cheng <icheng@nvidia.com>
>>>>>>>> ---
>>>>>>>>  tools/testing/selftests/resctrl/fill_buf.c | 11 +++++++++++
>>>>>>>>  1 file changed, 11 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/tools/testing/selftests/resctrl/fill_buf.c b/tools/testing/selftests/resctrl/fill_buf.c
>>>>>>>> index b9fa7968cd6e..eae0262fe265 100644
>>>>>>>> --- a/tools/testing/selftests/resctrl/fill_buf.c
>>>>>>>> +++ b/tools/testing/selftests/resctrl/fill_buf.c
>>>>>>>> @@ -27,6 +27,9 @@ static void sb(void)
>>>>>>>>  #if defined(__i386) || defined(__x86_64)
>>>>>>>>  	asm volatile("sfence\n\t"
>>>>>>>>  		     : : : "memory");
>>>>>>>> +#elif defined(__aarch64__)
>>>>>>>> +	asm volatile("dsb sy\n\t"
>>>>>>>> +		     : : : "memory");
>>>>>>>>  #endif
>>>>>>>>  }
>>>>>>>>  
>>>>>>>> @@ -35,6 +38,14 @@ static void cl_flush(void *p)
>>>>>>>>  #if defined(__i386) || defined(__x86_64)
>>>>>>>>  	asm volatile("clflush (%0)\n\t"
>>>>>>>>  		     : : "r"(p) : "memory");
>>>>>>>> +#elif defined(__aarch64__)
>>>>>>>> +	/*
>>>>>>>> +	 * Dirty the cache line with a store. As mem_flush() sweeps
>>>>>>>> +	 * the full test buffer (sized larger than the SLC), cache pressure
>>>>>>>> +	 * evicts lines from the SLC via LRU replacement.
>>>>>>>> +	 */
>>>>>>>> +	asm volatile("strb wzr, [%0]\n\t"
>>>>>>>> +		     : : "r"(p) : "memory");
>>>>>>>>  #endif
>>>>>>
>>>>>> One more thing that occurred to me is that if this is intended to evict all existing data in the
>>>>>> cache then it would require that the cache portions bitmap for the control group (PARTID) in use is
>>>>>> set to all 1s. E.g. 'L3:0=0xffff'. Otherwise, you may not affect the whole cache. This likely means
>>>>>> that the cl_flush() function isn't the right abstraction for MPAM and the test needs a bit of
>>>>>> restructuring to get this to fit in elegantly. Similarly, to the limbo handler in resctrl you could
>>>>>> then check the llc_occupancy() to check it's under a "low enough" threshold.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Ben
>>>>>>
>>>>>
>>>>> Hi Ben,
>>>>>
>>>>> Thanks for the feedback. I checked the code and ran some tests.
>>>>> You're right, my implementation writes into the benchmark's own buffer using
>>>>> the same PARRID/PMG, and the buffer isn't always larger than the SLC.
>>>>>
>>>>> I can't claim that it produces an eviction sweep 100%.
>>>>>
>>>>> I think what are want to do is to check whether reducing a group's cache
>>>>> allocation causes more cache misses, thus the data left in cache from the
>>>>> previous allocation must not affect the next measurement. That is also
>>>>> why I want to reuse the concept of Intel's test with CLFLUSH before
>>>>> warming the buffer under the new allocation.
>>>>>
>>>>> I'm thinking maybe the assumption can't be achieve on ARM, I ran tests to
>>>>> measure occupancy before and after each preparation method.
>>>>>
>>>>> I tried this patch's implement, and "DC CIVAC" since I think it can affectively
>>>>> invalidate cacheline without throwing old data away, which should left
>>>>> occupancy almost unchanged.
>>>>> And one more method with a separate large buffer in another group.
>>>>>
>>>>> The result turns out like the following
>>>>>
>>>>> Preparation                     Before (MiB)   After (MiB)
>>>>> DC CIVAC + DSB SY                     51.19         50.47
>>>>> zero-byte stores + DSB SY          53.12         56.43
>>>>> Separate-buffer pressure             53.25          7.14
>>>>>
>>>>>
>>>>> The current method increased the benchmark group's occupancy instead of
>>>>> reducing it. "DC CIVAC" left occupancy almost unchanged.
>>>>> The separate buffer method reduced occupancy very much, but still left data
>>>>> behind.
>>>>>
>>>>> It makes me think we should reconsider the test method. I think the goal is
>>>>> to check whether the MPAM allocation limit works, clearing the cache is only
>>>>> how the Intel RDT test prepares for that check.
>>>>>
>>>>> How about we set a group's mask before its worker initialize the buffer and
>>>>
>>>> We'll still need to make sure that the PARTID used for the test hasn't got high occupancy in the
>>>> cache before running the benchmark.
>>>>
>>>>> then run sustained cache traffic and measure occupancy after it settles?
>>>>
>>>> I assume the occupancy is measured via resctrl, llc_occupancy.
>>>>
>>>>> Maybe compare full, half and quarter masks to see whether the allocation limits take effect.
>>>>>
>>>>> Does that sound like a useful direction for MPAM test for you ?
>>>>
>>>> Yes, I think so.
>>>>
>>>> Would it end up like this?
>>>>
>>>> 1. Choose a test control group and ensure that it doesn't have high cache occupancy using llc_occupancy
>>>> (If it does have high cache occupancy then clean it. Probably by using separate buffer with a
>>>> separate control group)
>>>> 2. Configure the L3 cache bitmap for the test control group
>>>> 3. Run a benchmark
>>>> 4. Check that the llc_occupancy is as expected
>>>> 5. Repeat 1-4 with different cache bitmaps.
>>>>
>>>> However, it doesn't sound specific to MPAM but more like a general test for the cache portion
>>>> bitmap. Possibly it can be a separate cross-architecture resctrl selftest that compliments the
>>>> (somewhat) intel specific cat_test. (There isn't a platform independent way of measuring slc cache
>>>> misses on arm64.) This depends of the resctrl selftest maintainers view.
>>>>
>>>> Thanks,
>>>>
>>>> Ben
>>>>
>>>
>>> Hi Ben,
>>> I like the idea to make it a general test for cache on different arch,
>>> but yeah let's leave it for resctrl's maintainers to decide, I do not know other
>>> arch's cache topology and such so what I'm designing is very likely to overfit on ARM64.
>>>
>>> Anyway, per your suggestion, I tried a few experiment and came up with the approach
>>> like the following, and still have some points needs to discuss with you if you don't mind.
>>>
>>> We'll reuse one test group and buffer across tests for different bitmaps,
>>> and a separate group and buffer for sweeping.
>>>
>>> 1. Set up. Create the test and sweep group, assign workers, init buffer, give the sweep group the full cache mask.
>>> 2. Prepare before each mask. Keep the test worker stopped. Run the sweep worker and check "llc_occupancy" repeately,
>>> until it stays below a starting threshold, I set it as 4KB on my testing machine, we can discuss about it
>>
>> A starting threshold of 4KB on a machine with 164MB cache seems lower than required. Assuming, the
>> maximum number of cache portions supported by resctrl, 32, then each portion is about 5MB, and so if
>> you are measuring occupancy to check if the cache portion bitmap has the desired effect then 4KB is
>> in the noise.
>>
>>> since the value should fit on different machine. And we'll put a timeout for cleanup time.
>>> 3. Stop the sweep and apply cache maskWarmup test workload for 3 sec
>>> 4. Run the workloadRead llc_occupancy and see if it meets the expected value ( that's what we need to discuss )
>>>
>>> So on my machine it has a 164 MB share cache, no matter what cache masks I use, the cache occupancy won't be 100%,
>>> even I use some mask like 0001, 8000. I'm not sure what kind of expectation should we apply on the test,
>>> just not exceeding the rule's enforcement is enough ? or should it exceed certain amount of usage ?
>>
>>
>> I'd say just sufficient precision to be able distinguish between a cache bitmap with n bit set and
>> one with n + 1 bits.
>>
>> Does checking which of these intervals the occupancy in give you a reproducible way of determining
>> how many bits are set? Hopefully overshoot can be sized to make this reliable.
>>
>> (0, size/num_bits + overshoot),
>> (size/num_bits + overshoot, 2*size/num_bits + overshoot),
>> (2*size/num_bits + overshoot, 3*size/num_bits + overshoot),
>> ...
>> ((num_bits - 1)*size/num_bits + overshoot, size)
>>
>> As you mention above, making this reliable across architectures and even across arm platforms means
>> that you can't be just be looking for precise numbers or exactly repeatable behaviour.
>>
> Using benchmarks as a measure of resctrl health keeps giving problems due to the differences
> between systems. I cannot recall these tests failing because of an issue in resctrl self, which
> they are intended to test, yet they do fail and then need to be "tweaked" to accommodate some
> new architectural nuance that has nothing to do with the resctrl subsystem. For example,
> 
> 	https://lore.kernel.org/all/6de4da5486354c0f25fef0d194956470cb744041.1775266384.git.reinette.chatre@intel.com/
> 
> Please take a moment and consider what you want to achieve with these tests: what is this
> intended to test? In a way the benchmarks seem to be testing the hardware capabilities and useful
> to hardware validation folks more so than testing resctrl subsystem in a useful way to
> kernel development. 
> 
> More specifically, if this test "fails" - is there *anything* we can do about
> it that does not involve "fixing" the test? 
> 
> In the end I find these performance tests valuable in how they interact with the
> resctrl filesystem in different ways, not the actual performance values returned by the tests.

I think the actual performance testing can be left to those testing and
evaluating particular platforms.

> > Of course it is up to you, I am just concerned that you may end up
(as I have) spending a lot
> of effort on work that does not end up being a deterministic measurement of resctrl health yet
> is used to produce a "pass" or "fail" verdict about resctrl subsystem health.

Indeed, I don't think any of us have the time to chase tuning parameters
for a test. Especially, one that runs on multiple architectures.

> 
> If you do end up using a benchmark I'd suggest to make the checks as forgiving as
> possible. For example, instead of checking something like "LLC occupancy needs to be
> X when bitmap is Y" it should check something like "LLC occupancy when bitmap is all ones
> is larger than LLC occupancy when only half of bitmap is ones".

Do you think it's too strong to say that a bitmap with n + 1 bits set
has higher occupancy than one with n bits set? I think it has slightly
more utility in that all bits of the bitmap are plumbed down to a
working control but I'm ok with a weaker check if a stronger check will
just be problematic and maintenance heavy.

> 
> I find work like
> 
> 	https://lore.kernel.org/all/20260810095124.32244-1-icheng@nvidia.com/
> 
> to be valuable as deterministic measurements of resctrl health.

Yes, they do look useful.

Thanks,

Ben

> 
> Reinette

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Ben Horgan]

On 14/11/2026 03:16, Ben Horgan wrote:
> Hi Reinette and Richard,
> 
Apologies for the time travelling.

Ben

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Reinette Chatre]

Hi Ben,

On 11/13/26 7:16 PM, Ben Horgan wrote:
> On 07/11/2026 00:29, Reinette Chatre wrote:

... 
>>
>> If you do end up using a benchmark I'd suggest to make the checks as forgiving as
>> possible. For example, instead of checking something like "LLC occupancy needs to be
>> X when bitmap is Y" it should check something like "LLC occupancy when bitmap is all ones
>> is larger than LLC occupancy when only half of bitmap is ones".
> 
> Do you think it's too strong to say that a bitmap with n + 1 bits set
> has higher occupancy than one with n bits set? I think it has slightly
> more utility in that all bits of the bitmap are plumbed down to a
> working control but I'm ok with a weaker check if a stronger check will
> just be problematic and maintenance heavy.

My comment was motivated by the recent change I needed to make to the CAT test
that uses cache misses measured via perf instead of cache occupancy. Originally
this test incremented the bitmap with one at each cycle but incrementing it with
two proved to be more robust.

What you are proposing sounds more like an enhancement to the CMT test that
uses cache occupancy as measurement while following the same methodology as the
CAT test. At the moment the CMT test just uses a single cycle of a hardcoded
(unless user provides something else) bitmap with five bits set. Even with this
I needed add enhancements to make it more robust:

 commit ca0ea39288c9 ("selftests/resctrl: Reduce interference from L2 occupancy during cache occupancy test")
 commit 7a214b4ec1c9 ("selftests/resctrl: Improve accuracy of cache occupancy test")

As one enhancement highlights the accuracy can be managed better on a system that
supports L2 as well as L3 allocation. Not all systems able to run such test will have such
capability. Also, looks like CMT does not require there to not be interference as the CAT
test does but with MPAM systems having each cache portion as shareable this may also be
a big influence on accuracy.

I am not able to judge if a test that uses LLC occupancy and relies on single bit increments
will be robust across all platforms of all architectures. Even so, I do see several risks
for such test to be reliable while I do not see how such fine grained increment provides
insight into resctrl kernel subsystem health.

Reinette

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Richard Cheng]

On Mon, Nov 09, 2026 at 09:01:18AM +0800, Reinette Chatre wrote:
> Hi Ben,
> 
> On 11/13/26 7:16 PM, Ben Horgan wrote:
> > On 07/11/2026 00:29, Reinette Chatre wrote:
> 
> ... 
> >>
> >> If you do end up using a benchmark I'd suggest to make the checks as forgiving as
> >> possible. For example, instead of checking something like "LLC occupancy needs to be
> >> X when bitmap is Y" it should check something like "LLC occupancy when bitmap is all ones
> >> is larger than LLC occupancy when only half of bitmap is ones".
> > 
> > Do you think it's too strong to say that a bitmap with n + 1 bits set
> > has higher occupancy than one with n bits set? I think it has slightly
> > more utility in that all bits of the bitmap are plumbed down to a
> > working control but I'm ok with a weaker check if a stronger check will
> > just be problematic and maintenance heavy.
> 
> My comment was motivated by the recent change I needed to make to the CAT test
> that uses cache misses measured via perf instead of cache occupancy. Originally
> this test incremented the bitmap with one at each cycle but incrementing it with
> two proved to be more robust.
> 
> What you are proposing sounds more like an enhancement to the CMT test that
> uses cache occupancy as measurement while following the same methodology as the
> CAT test. At the moment the CMT test just uses a single cycle of a hardcoded
> (unless user provides something else) bitmap with five bits set. Even with this
> I needed add enhancements to make it more robust:
> 
>  commit ca0ea39288c9 ("selftests/resctrl: Reduce interference from L2 occupancy during cache occupancy test")
>  commit 7a214b4ec1c9 ("selftests/resctrl: Improve accuracy of cache occupancy test")
> 
> As one enhancement highlights the accuracy can be managed better on a system that
> supports L2 as well as L3 allocation. Not all systems able to run such test will have such
> capability. Also, looks like CMT does not require there to not be interference as the CAT
> test does but with MPAM systems having each cache portion as shareable this may also be
> a big influence on accuracy.
> 
> I am not able to judge if a test that uses LLC occupancy and relies on single bit increments
> will be robust across all platforms of all architectures. Even so, I do see several risks
> for such test to be reliable while I do not see how such fine grained increment provides
> insight into resctrl kernel subsystem health.
> 
> Reinette
> 
>

Hi Ben, Reinette,

I am thinking what about thinking in reserve ?
Maybe narrow the test to detect an ignored or overly permissive allocation
resctriction ?

Imagine a small cache mask 0x001, and check whether occupancy exceed the
capacity represented by that bitmap.
L2 effect or lack of control for L2 thus won't be an issue here.

Ofcourse we still need to think of how to cleanup pre-existing occupancy,
or a whole new workload everytime that the pattern is guaranteed to be
freshly new.

Thoughts ?

Best regards,
Richard Cheng.
 

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Ben Horgan]

Hi Richard,

On 10/11/2026 07:33, Richard Cheng wrote:
> On Mon, Nov 09, 2026 at 09:01:18AM +0800, Reinette Chatre wrote:
>> Hi Ben,
>>
>> On 11/13/26 7:16 PM, Ben Horgan wrote:
>>> On 07/11/2026 00:29, Reinette Chatre wrote:
>>
>> ... 
>>>>
>>>> If you do end up using a benchmark I'd suggest to make the checks as forgiving as
>>>> possible. For example, instead of checking something like "LLC occupancy needs to be
>>>> X when bitmap is Y" it should check something like "LLC occupancy when bitmap is all ones
>>>> is larger than LLC occupancy when only half of bitmap is ones".
>>>
>>> Do you think it's too strong to say that a bitmap with n + 1 bits set
>>> has higher occupancy than one with n bits set? I think it has slightly
>>> more utility in that all bits of the bitmap are plumbed down to a
>>> working control but I'm ok with a weaker check if a stronger check will
>>> just be problematic and maintenance heavy.
>>
>> My comment was motivated by the recent change I needed to make to the CAT test
>> that uses cache misses measured via perf instead of cache occupancy. Originally
>> this test incremented the bitmap with one at each cycle but incrementing it with
>> two proved to be more robust.
>>
>> What you are proposing sounds more like an enhancement to the CMT test that
>> uses cache occupancy as measurement while following the same methodology as the
>> CAT test. At the moment the CMT test just uses a single cycle of a hardcoded
>> (unless user provides something else) bitmap with five bits set. Even with this
>> I needed add enhancements to make it more robust:
>>
>>  commit ca0ea39288c9 ("selftests/resctrl: Reduce interference from L2 occupancy during cache occupancy test")
>>  commit 7a214b4ec1c9 ("selftests/resctrl: Improve accuracy of cache occupancy test")
>>
>> As one enhancement highlights the accuracy can be managed better on a system that
>> supports L2 as well as L3 allocation. Not all systems able to run such test will have such
>> capability. Also, looks like CMT does not require there to not be interference as the CAT
>> test does but with MPAM systems having each cache portion as shareable this may also be
>> a big influence on accuracy.
>>
>> I am not able to judge if a test that uses LLC occupancy and relies on single bit increments
>> will be robust across all platforms of all architectures. Even so, I do see several risks
>> for such test to be reliable while I do not see how such fine grained increment provides
>> insight into resctrl kernel subsystem health.
>>
>> Reinette
>>
>>
> 
> Hi Ben, Reinette,
> 
> I am thinking what about thinking in reserve ?
> Maybe narrow the test to detect an ignored or overly permissive allocation
> resctriction ?
> 
> Imagine a small cache mask 0x001, and check whether occupancy exceed the
> capacity represented by that bitmap.
> L2 effect or lack of control for L2 thus won't be an issue here.


I expect there will still be inaccuracies here. Perhaps more so in architectures other than MPAM
where RMID and CLOSID are disjoint as then monitoring and controls rely on different identifiers in
the system. I am happy with whatever is simple and reliable.

Thanks,

Ben

> 
> Ofcourse we still need to think of how to cleanup pre-existing occupancy,
> or a whole new workload everytime that the pattern is guaranteed to be
> freshly new.
> 
> Thoughts ?
> 
> Best regards,
> Richard Cheng.
>  

Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64

[Ben Horgan]

Hi Reinette, Richard,

On 09/11/2026 17:01, Reinette Chatre wrote:
> Hi Ben,
> 
> On 11/13/26 7:16 PM, Ben Horgan wrote:
>> On 07/11/2026 00:29, Reinette Chatre wrote:
> 
> ... 
>>>
>>> If you do end up using a benchmark I'd suggest to make the checks as forgiving as
>>> possible. For example, instead of checking something like "LLC occupancy needs to be
>>> X when bitmap is Y" it should check something like "LLC occupancy when bitmap is all ones
>>> is larger than LLC occupancy when only half of bitmap is ones".
>>
>> Do you think it's too strong to say that a bitmap with n + 1 bits set
>> has higher occupancy than one with n bits set? I think it has slightly
>> more utility in that all bits of the bitmap are plumbed down to a
>> working control but I'm ok with a weaker check if a stronger check will
>> just be problematic and maintenance heavy.
> 
> My comment was motivated by the recent change I needed to make to the CAT test
> that uses cache misses measured via perf instead of cache occupancy. Originally
> this test incremented the bitmap with one at each cycle but incrementing it with
> two proved to be more robust.
> 
> What you are proposing sounds more like an enhancement to the CMT test that
> uses cache occupancy as measurement while following the same methodology as the
> CAT test. 

Ok, then perhaps it's best just to enhance the CMT test to also check that the cache allocation
bitmap has some measureable effect rather than a new test. In the spirit of making the checks as
weak as possible we could just check that the measured llc_occupancy is lowest for the minimum
number of cache allocation bits set, higher when half the bits set and highest when all the bits are
set.

This brings us back to the initial subject of this patch. For MPAM we need a new implementation for
memflush() as cl_flush() doesn't have a direct equivalent on arm64. There is an smmcc based option
but the kernel support isn't upstream yet [1] and I don't know how widely it is supported in
firmware. As such, we need to use the writing of a buffer from a different control group. This
should be distinct from the default control group and have all cache portion bits set, as the CMT
test uses the inverse of the testing mask for the default group. The llc_occupancy of the testing
group can be used to check the group is clean enough, i.e. the memflush() had the desired effect.
All this does have the disadvantage of using the same features we are checking to to help with the
testing interface but there seems no easy way out of that while staying generic across even MPAM
platforms.

[1] https://lore.kernel.org/linux-arm-kernel/20261021224557.1827361-1-smadhavan@nvidia.com/

At the moment the CMT test just uses a single cycle of a hardcoded
> (unless user provides something else) bitmap with five bits set. Even with this
> I needed add enhancements to make it more robust:
> 
>  commit ca0ea39288c9 ("selftests/resctrl: Reduce interference from L2 occupancy during cache occupancy test")
>  commit 7a214b4ec1c9 ("selftests/resctrl: Improve accuracy of cache occupancy test")
> 
> As one enhancement highlights the accuracy can be managed better on a system that
> supports L2 as well as L3 allocation. Not all systems able to run such test will have such
> capability. Also, looks like CMT does not require there to not be interference as the CAT
> test does but with MPAM systems having each cache portion as shareable this may also be
> a big influence on accuracy.
> 
> I am not able to judge if a test that uses LLC occupancy and relies on single bit increments
> will be robust across all platforms of all architectures. Even so, I do see several risks
> for such test to be reliable while I do not see how such fine grained increment provides
> insight into resctrl kernel subsystem health.

Thanks for sharing your experience on the testing robustness. I now see that being as permissive as
possible with our testing is the way to go.

Ben

> 
> Reinette
> 
> 

[PATCH v5 2/2] selftests/resctrl: Recognise aarch64 as a vendor for L3_NONCONT_CAT

[Richard Cheng]

aarch64 has no vendor_id in /proc/cpuinfo, so detect_vendor() returns 0
and arch_supports_noncont_cat() falls through to "return false".
L3_NONCONT_CAT therefore spuriously fails on every ARM MPAM platform.

Define ARCH_ARM, short-circuit detect_vendor() to it on aarch64, and
add it to the AMD/Hygon always-supports early-out in
arch_supports_noncont_cat().

aarch64 has many implementers (ARM 0x41, NVIDIA 0x43, etc.), but MPAM
mandates non-contiguous CPBM uniformly, so per-implementer handling is
not needed here.

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Richard Cheng <icheng@nvidia.com>
---
 tools/testing/selftests/resctrl/cat_test.c    |  9 ++++++--
 tools/testing/selftests/resctrl/resctrl.h     |  1 +
 .../testing/selftests/resctrl/resctrl_tests.c | 21 +++++++++++++++++++
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/resctrl/cat_test.c b/tools/testing/selftests/resctrl/cat_test.c
index 0a417267dd74..f4b02b3eedd7 100644
--- a/tools/testing/selftests/resctrl/cat_test.c
+++ b/tools/testing/selftests/resctrl/cat_test.c
@@ -271,8 +271,13 @@ static bool arch_supports_noncont_cat(const struct resctrl_test *test)
 {
 	unsigned int vendor_id = get_vendor();
 
-	/* AMD and Hygon always support non-contiguous CBM. */
-	if (vendor_id == ARCH_AMD || vendor_id == ARCH_HYGON)
+	/*
+	 * AMD and Hygon always support non-contiguous CBM. ARM/MPAM defines
+	 * MPAMCFG_CPBM as a bitmap with no contiguity constraint per ARM
+	 * DDI 0598.
+	 */
+	if (vendor_id == ARCH_AMD || vendor_id == ARCH_HYGON ||
+	    vendor_id == ARCH_ARM)
 		return true;
 
 #if defined(__i386__) || defined(__x86_64__) /* arch */
diff --git a/tools/testing/selftests/resctrl/resctrl.h b/tools/testing/selftests/resctrl/resctrl.h
index a7556cdae0de..03b4500c1f7f 100644
--- a/tools/testing/selftests/resctrl/resctrl.h
+++ b/tools/testing/selftests/resctrl/resctrl.h
@@ -41,6 +41,7 @@
 #define ARCH_INTEL	BIT(0)
 #define ARCH_AMD	BIT(1)
 #define ARCH_HYGON	BIT(2)
+#define ARCH_ARM	BIT(3)
 
 #define END_OF_TESTS	1
 
diff --git a/tools/testing/selftests/resctrl/resctrl_tests.c b/tools/testing/selftests/resctrl/resctrl_tests.c
index dbcd5eea9fbc..cfece594a8c6 100644
--- a/tools/testing/selftests/resctrl/resctrl_tests.c
+++ b/tools/testing/selftests/resctrl/resctrl_tests.c
@@ -23,6 +23,15 @@ static struct resctrl_test *resctrl_tests[] = {
 	&l2_noncont_cat_test,
 };
 
+static bool detect_aarch64(void)
+{
+#if defined(__aarch64__)
+	return true;
+#else
+	return false;
+#endif
+}
+
 static unsigned int detect_vendor(void)
 {
 	static unsigned int vendor_id;
@@ -34,6 +43,18 @@ static unsigned int detect_vendor(void)
 	if (initialized)
 		return vendor_id;
 
+	if (detect_aarch64()) {
+		/*
+		 * aarch64 has no userspace vendor_id in /proc/cpuinfo.
+		 * MPAM-capable ARM implementations follow ARM DDI 0598;
+		 * treat all aarch64 builds as a single vendor for the
+		 * purposes of resctrl selftests.
+		 */
+		vendor_id = ARCH_ARM;
+		initialized = true;
+		return vendor_id;
+	}
+
 	inf = fopen("/proc/cpuinfo", "r");
 	if (!inf) {
 		vendor_id = 0;
-- 
2.43.0

Re: [PATCH v5 2/2] selftests/resctrl: Recognise aarch64 as a vendor for L3_NONCONT_CAT

[Ben Horgan]

Hi Richard,

On 12/10/2026 08:47, Richard Cheng wrote:
> aarch64 has no vendor_id in /proc/cpuinfo, so detect_vendor() returns 0
> and arch_supports_noncont_cat() falls through to "return false".
> L3_NONCONT_CAT therefore spuriously fails on every ARM MPAM platform.
> 
> Define ARCH_ARM, short-circuit detect_vendor() to it on aarch64, and
> add it to the AMD/Hygon always-supports early-out in
> arch_supports_noncont_cat().
> 
> aarch64 has many implementers (ARM 0x41, NVIDIA 0x43, etc.), but MPAM
> mandates non-contiguous CPBM uniformly, so per-implementer handling is
> not needed here.
> 
> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
> Signed-off-by: Richard Cheng <icheng@nvidia.com>
> ---
>  tools/testing/selftests/resctrl/cat_test.c    |  9 ++++++--
>  tools/testing/selftests/resctrl/resctrl.h     |  1 +
>  .../testing/selftests/resctrl/resctrl_tests.c | 21 +++++++++++++++++++
>  3 files changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/selftests/resctrl/cat_test.c b/tools/testing/selftests/resctrl/cat_test.c
> index 0a417267dd74..f4b02b3eedd7 100644
> --- a/tools/testing/selftests/resctrl/cat_test.c
> +++ b/tools/testing/selftests/resctrl/cat_test.c
> @@ -271,8 +271,13 @@ static bool arch_supports_noncont_cat(const struct resctrl_test *test)
>  {
>  	unsigned int vendor_id = get_vendor();
>  
> -	/* AMD and Hygon always support non-contiguous CBM. */
> -	if (vendor_id == ARCH_AMD || vendor_id == ARCH_HYGON)
> +	/*
> +	 * AMD and Hygon always support non-contiguous CBM. ARM/MPAM defines
> +	 * MPAMCFG_CPBM as a bitmap with no contiguity constraint per ARM
> +	 * DDI 0598.
> +	 */
> +	if (vendor_id == ARCH_AMD || vendor_id == ARCH_HYGON ||
> +	    vendor_id == ARCH_ARM)
>  		return true;

Would it be better not to just to use the information resctrl advertises?
/sys/fs/resctrl/info/L3/sparse_masks

Is there any reason this test doesn't use that other than being written before its introduction?

Thanks,

Ben

>  
>  #if defined(__i386__) || defined(__x86_64__) /* arch */
> diff --git a/tools/testing/selftests/resctrl/resctrl.h b/tools/testing/selftests/resctrl/resctrl.h
> index a7556cdae0de..03b4500c1f7f 100644
> --- a/tools/testing/selftests/resctrl/resctrl.h
> +++ b/tools/testing/selftests/resctrl/resctrl.h
> @@ -41,6 +41,7 @@
>  #define ARCH_INTEL	BIT(0)
>  #define ARCH_AMD	BIT(1)
>  #define ARCH_HYGON	BIT(2)
> +#define ARCH_ARM	BIT(3)
>  
>  #define END_OF_TESTS	1
>  
> diff --git a/tools/testing/selftests/resctrl/resctrl_tests.c b/tools/testing/selftests/resctrl/resctrl_tests.c
> index dbcd5eea9fbc..cfece594a8c6 100644
> --- a/tools/testing/selftests/resctrl/resctrl_tests.c
> +++ b/tools/testing/selftests/resctrl/resctrl_tests.c
> @@ -23,6 +23,15 @@ static struct resctrl_test *resctrl_tests[] = {
>  	&l2_noncont_cat_test,
>  };
>  
> +static bool detect_aarch64(void)
> +{
> +#if defined(__aarch64__)
> +	return true;
> +#else
> +	return false;
> +#endif
> +}
> +
>  static unsigned int detect_vendor(void)
>  {
>  	static unsigned int vendor_id;
> @@ -34,6 +43,18 @@ static unsigned int detect_vendor(void)
>  	if (initialized)
>  		return vendor_id;
>  
> +	if (detect_aarch64()) {
> +		/*
> +		 * aarch64 has no userspace vendor_id in /proc/cpuinfo.
> +		 * MPAM-capable ARM implementations follow ARM DDI 0598;
> +		 * treat all aarch64 builds as a single vendor for the
> +		 * purposes of resctrl selftests.
> +		 */
> +		vendor_id = ARCH_ARM;
> +		initialized = true;
> +		return vendor_id;
> +	}
> +
>  	inf = fopen("/proc/cpuinfo", "r");
>  	if (!inf) {
>  		vendor_id = 0;

Re: [PATCH v5 2/2] selftests/resctrl: Recognise aarch64 as a vendor for L3_NONCONT_CAT

[Reinette Chatre]

Hi Ben,

On 10/20/26 9:18 AM, Ben Horgan wrote:
> On 12/10/2026 08:47, Richard Cheng wrote:

>> diff --git a/tools/testing/selftests/resctrl/cat_test.c b/tools/testing/selftests/resctrl/cat_test.c
>> index 0a417267dd74..f4b02b3eedd7 100644
>> --- a/tools/testing/selftests/resctrl/cat_test.c
>> +++ b/tools/testing/selftests/resctrl/cat_test.c
>> @@ -271,8 +271,13 @@ static bool arch_supports_noncont_cat(const struct resctrl_test *test)
>>  {
>>  	unsigned int vendor_id = get_vendor();
>>  
>> -	/* AMD and Hygon always support non-contiguous CBM. */
>> -	if (vendor_id == ARCH_AMD || vendor_id == ARCH_HYGON)
>> +	/*
>> +	 * AMD and Hygon always support non-contiguous CBM. ARM/MPAM defines
>> +	 * MPAMCFG_CPBM as a bitmap with no contiguity constraint per ARM
>> +	 * DDI 0598.
>> +	 */
>> +	if (vendor_id == ARCH_AMD || vendor_id == ARCH_HYGON ||
>> +	    vendor_id == ARCH_ARM)
>>  		return true;
> 
> Would it be better not to just to use the information resctrl advertises?
> /sys/fs/resctrl/info/L3/sparse_masks

The result of this architecture specific test is used to validate that 
/sys/fs/resctrl/info/L3/sparse_masks provides accurate information.

This test was originally developed on Intel where support for
sparse masks need to be discovered from the hardware. 

> 
> Is there any reason this test doesn't use that other than being written before its introduction?
Reinette

Re: [PATCH v5 2/2] selftests/resctrl: Recognise aarch64 as a vendor for L3_NONCONT_CAT

[Ben Horgan]

Hi Reinette, Richard,

On 21/10/2026 15:56, Reinette Chatre wrote:
> Hi Ben,
> 
> On 10/20/26 9:18 AM, Ben Horgan wrote:
>> On 12/10/2026 08:47, Richard Cheng wrote:
> 
>>> diff --git a/tools/testing/selftests/resctrl/cat_test.c b/tools/testing/selftests/resctrl/cat_test.c
>>> index 0a417267dd74..f4b02b3eedd7 100644
>>> --- a/tools/testing/selftests/resctrl/cat_test.c
>>> +++ b/tools/testing/selftests/resctrl/cat_test.c
>>> @@ -271,8 +271,13 @@ static bool arch_supports_noncont_cat(const struct resctrl_test *test)
>>>  {
>>>  	unsigned int vendor_id = get_vendor();
>>>  
>>> -	/* AMD and Hygon always support non-contiguous CBM. */
>>> -	if (vendor_id == ARCH_AMD || vendor_id == ARCH_HYGON)
>>> +	/*
>>> +	 * AMD and Hygon always support non-contiguous CBM. ARM/MPAM defines
>>> +	 * MPAMCFG_CPBM as a bitmap with no contiguity constraint per ARM
>>> +	 * DDI 0598.

Nit: DDI 0598 is retired. The new spec version is IHI0099.

>>> +	 */
>>> +	if (vendor_id == ARCH_AMD || vendor_id == ARCH_HYGON ||
>>> +	    vendor_id == ARCH_ARM)
>>>  		return true;
>>
>> Would it be better not to just to use the information resctrl advertises?
>> /sys/fs/resctrl/info/L3/sparse_masks
> 
> The result of this architecture specific test is used to validate that 
> /sys/fs/resctrl/info/L3/sparse_masks provides accurate information.
> 
> This test was originally developed on Intel where support for
> sparse masks need to be discovered from the hardware. 

Ah ok, thanks for putting me straight.  The defined(__aarch64__) check looks to be the common way of
checking in the selftests. This looks fine to me.

Reviewed-by: Ben Horgan <ben.horgan@arm.com>

Thanks,

Ben

> 
>>
>> Is there any reason this test doesn't use that other than being written before its introduction?
> Reinette

Re: [PATCH v5 0/2] selftests/resctrl: Fix resctrl selftests issues on aarch64

[Reinette Chatre]

+Ben

Hi Everybody,

Could the Arm/MPAM folks please consider this series?

Thank you very much.

Reinette

On 10/12/26 12:47 AM, Richard Cheng wrote:
> This series fixes issues in the resctrl selftests on aarch64,
> where they currently misreport failures.
> 
> Patch 1 adds aarch64 implementations of cl_flush() and sb() in
> fill_buf.c so cache flushes are no longer silent no-ops.
> 
> Patch 2 teaches detect_vendor() about aarch64 (which exposes no
> vendor_id in /proc/cpuinfo) and lets arch_supports_noncont_cat()
> return true for ARM, fixing spurious L3_NONCONT_CAT failures.
> 
> Changes since v4:
> - Drop v4 patch 1/3, which was applied to linux-kselftest/next.
> - Rebase the remaining patches onto linux-kselftest/next and
>   renumber v4 patches 2/3 and 3/3 as patches 1/2 and 2/2.
>   No code changes to the remaining patches.
> 
> Richard Cheng (2):
>   selftests/resctrl: Implement cl_flush() and sb() for aarch64
>   selftests/resctrl: Recognise aarch64 as a vendor for L3_NONCONT_CAT
> 
>  tools/testing/selftests/resctrl/cat_test.c    |  9 ++++++--
>  tools/testing/selftests/resctrl/fill_buf.c    | 11 ++++++++++
>  tools/testing/selftests/resctrl/resctrl.h     |  1 +
>  .../testing/selftests/resctrl/resctrl_tests.c | 21 +++++++++++++++++++
>  4 files changed, 40 insertions(+), 2 deletions(-)
> 
> 
> base-commit: 30af56a227e27b892d34bc44c23298b5274913e3