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

[Ben Horgan <ben.horgan@arm.com>]

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