lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 14 Mar 2022 18:00:13 +0000
From:   German Gomez <german.gomez@....com>
To:     Leo Yan <leo.yan@...aro.org>, Ali Saidi <alisaidi@...zon.com>
Cc:     acme@...nel.org, alexander.shishkin@...ux.intel.com,
        andrew.kilroy@....com, benh@...nel.crashing.org,
        james.clark@....com, john.garry@...wei.com, jolsa@...nel.org,
        kjain@...ux.ibm.com, lihuafei1@...wei.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-perf-users@...r.kernel.org, mark.rutland@....com,
        mathieu.poirier@...aro.org, mingo@...hat.com, namhyung@...nel.org,
        peterz@...radead.org, will@...nel.org, yao.jin@...ux.intel.com,
        Nick.Forrington@....com
Subject: Re: [PATCH v2 2/2] perf mem: Support HITM for when mem_lvl_num is
 used

Hi Leo, Ali

On 14/03/2022 06:33, Leo Yan wrote:
> On Sun, Mar 13, 2022 at 07:19:33PM +0000, Ali Saidi wrote:
>
> [...]
>
>>>>> +			if (lvl & P(LVL, L3) || lnum == P(LVLNUM, L4)) {
>>>> According to a comment in the previous patch, using L4 is specific to Neoverse, right?
>>>>
>>>> Maybe we need to distinguish the Neoverse case from the generic one here as well
>>>>
>>>> if (is_neoverse)
>>>> // treat L4 as llc
>>>> else
>>>> // treat L3 as llc
>>> I personally think it's not good idea to distinguish platforms in the decoding code.
>> I agree here. The more we talk about this, the more I'm wondering if we're
>> spending too much code solving a problem that doesn't exist. I know of no
>> Neoverse systems that actually have 4 cache levels, they all actually have three
>> even though it's technically possible to have four.  I have some doubts anyone
>> will actually build four levels of cache and perhaps the most prudent path here
>> is to assume only three levels (and adjust the previous patch) until someone 
>> actually produces a system with four levels instead of a lot of code that is
>> never actually exercised?
> I am not right person to say L4 cache is not implemented in Neoverse
> platforms; my guess for a "System cache" data source might be L3 or
> L4 and it is a implementation dependent.  Maybe German or Arm mates
> could confirm for this.

I had a look at the TRMs for the N1[1], V1[2] and N2[3] Neoverse cores
(specifically the LL_CACHE_RD pmu events). If we were to assign a number
to the system cache (assuming all caches are implemented):

*For N1*, if L2 and L3 are implemented, system cache would follow at *L4*

*For V1 and N2*, if L2 is implemented, system cache would follow at *L3*
(these don't seem to have the same/similar per-cluster L3 cache from the N1)

There's also room in the PERF_MEM_LVLNUM_* namespace for a SYSTEM value,
if we want to consider that option as well.

[1] https://developer.arm.com/documentation/100616/0401/?lang=en
[2] https://developer.arm.com/documentation/101427/0101/?lang=en
[3] https://developer.arm.com/documentation/102099/0001/?lang=en

>
> Thanks,
> Leo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ