[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48c6795b-554a-4019-bb8d-a2ca0f6fbb2b@intel.com>
Date: Fri, 3 Nov 2023 15:53:23 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
CC: <linux-kselftest@...r.kernel.org>, Shuah Khan <shuah@...nel.org>,
"Shaopeng Tan" <tan.shaopeng@...fujitsu.com>,
Maciej Wieczór-Retman
<maciej.wieczor-retman@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 23/24] selftests/resctrl: Add L2 CAT test
Hi Ilpo,
On 11/3/2023 3:39 AM, Ilpo Järvinen wrote:
> On Thu, 2 Nov 2023, Reinette Chatre wrote:
>> On 10/24/2023 2:26 AM, Ilpo Järvinen wrote:
>
>>> Add L2 CAT selftest. As measuring L2 misses is not easily available
>>> with perf, use L3 accesses as a proxy for L2 CAT working or not.
>>
>> I understand the exact measurement is not available but I do notice some
>> L2 related symbolic counters when I run "perf list". l2_rqsts.all_demand_miss
>> looks promising.
>
> Okay, I was under impression that L2 misses are not available. Both based
> on what you mentioned to me half an year ago and because of what flags I
> found from the header. But I'll take another look into it.
You are correct that when I did L2 testing a long time ago I used
the model specific L2 miss counts. I was hoping that things have improved
so that model specific counters are not needed, as you have tried here.
I found the l2_rqsts symbol while looking for alternatives but I am not
familiar enough with perf to know how these symbolic names are mapped.
I was hoping that they could be a simple drop-in replacement to
experiment with.
>
>> L3 cannot be relied on for those systems, like Apollo lake, that do
>> not have an L3.
>
> Do you happen know what perf will report for such CPUs, will it return
> L2 as LLC?
I don't know.
>
>>> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
>>> ---
>>> tools/testing/selftests/resctrl/cat_test.c | 68 +++++++++++++++++--
>>> tools/testing/selftests/resctrl/resctrl.h | 1 +
>>> .../testing/selftests/resctrl/resctrl_tests.c | 1 +
>>> 3 files changed, 63 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/tools/testing/selftests/resctrl/cat_test.c b/tools/testing/selftests/resctrl/cat_test.c
>>> index 48a96acd9e31..a9c72022bb5a 100644
>>> --- a/tools/testing/selftests/resctrl/cat_test.c
>>> +++ b/tools/testing/selftests/resctrl/cat_test.c
>>> @@ -131,8 +131,47 @@ void cat_test_cleanup(void)
>>> remove(RESULT_FILE_NAME);
>>> }
>>>
>>> +/*
>>> + * L2 CAT test measures L2 misses indirectly using L3 accesses as a proxy
>>> + * because perf cannot directly provide the number of L2 misses (there are
>>> + * only platform specific ways to get the number of L2 misses).
>>> + *
>>> + * This function sets up L3 CAT to reduce noise from other processes during
>>> + * L2 CAT test.
>>
>> This motivation is not clear to me. Does the same isolation used during
>> L3 CAT testing not work? I expected it to follow the same idea with the
>> L2 cache split in two, the test using one part and the rest of the
>> system using the other. Is that not enough isolation?
>
> Isolation for L2 is done very same way as with L3 and I think it itself
> works just fine.
>
> However, because L2 CAT selftest as is measures L3 accesses that in ideal
> world equals to L2 misses, isolating selftest related L3 accesses from the
> rest of the system should reduce noise in the # of L3 accesses. It's not
> mandatory though so if L3 CAT is not available the function just prints a
> warning about the potential noise and does setup nothing for L3.
This is not clear to me. If the read misses L2 and then accesses L3 then
it should not matter which part of L3 cache the work is isolated to. What noise
do you have in mind?
Reinette
Powered by blists - more mailing lists