From: Ben Horgan <ben.horgan@arm.com>
To: Richard Cheng <icheng@nvidia.com>,
Reinette Chatre <reinette.chatre@intel.com>
Cc: tony.luck@intel.com, x86@kernel.org, shuah@kernel.org,
fenghuay@nvidia.com, Dave.Martin@arm.com, james.morse@arm.com,
babu.moger@amd.com, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, kaihengf@nvidia.com,
kobak@nvidia.com, newtonl@nvidia.com, kristinc@nvidia.com
Subject: Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64
Date: Tue, 10 Nov 2026 13:50:41 +0000 [thread overview]
Message-ID: <e65a384f-602f-4bd3-9071-5816b2bd4a50@arm.com> (raw)
In-Reply-To: <avLF-PLcSFCDow5S@MWDK4CY14F>
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.
>
next prev parent reply other threads:[~2026-11-10 13:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 7:47 [PATCH v5 0/2] selftests/resctrl: Fix resctrl selftests issues on aarch64 Richard Cheng
2026-10-12 7:47 ` [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64 Richard Cheng
2026-10-20 16:30 ` Ben Horgan
2026-10-21 9:55 ` Ben Horgan
2026-11-04 6:43 ` Richard Cheng
2026-11-04 17:09 ` Ben Horgan
2026-11-05 9:41 ` Richard Cheng
2026-11-06 15:53 ` Ben Horgan
2026-11-07 0:29 ` Reinette Chatre
2026-11-14 3:16 ` Ben Horgan
2026-11-09 10:21 ` Ben Horgan
2026-11-09 17:01 ` Reinette Chatre
2026-11-10 7:33 ` Richard Cheng
2026-11-10 13:50 ` Ben Horgan [this message]
2026-11-10 12:35 ` Ben Horgan
2026-10-12 7:47 ` [PATCH v5 2/2] selftests/resctrl: Recognise aarch64 as a vendor for L3_NONCONT_CAT Richard Cheng
2026-10-20 16:18 ` Ben Horgan
2026-10-21 14:56 ` Reinette Chatre
2026-10-21 16:31 ` Ben Horgan
2026-10-12 22:09 ` [PATCH v5 0/2] selftests/resctrl: Fix resctrl selftests issues on aarch64 Reinette Chatre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e65a384f-602f-4bd3-9071-5816b2bd4a50@arm.com \
--to=ben.horgan@arm.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=fenghuay@nvidia.com \
--cc=icheng@nvidia.com \
--cc=james.morse@arm.com \
--cc=kaihengf@nvidia.com \
--cc=kobak@nvidia.com \
--cc=kristinc@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=newtonl@nvidia.com \
--cc=reinette.chatre@intel.com \
--cc=shuah@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®