linux-kernel - Re: [PATCH v2 1/2] perf arm-spe: Use SPE data source for neoverse cores

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 12:05:42 +0800
From:   Leo Yan <leo.yan@...aro.org>
To:     Ali Saidi <alisaidi@...zon.com>
Cc:     acme@...nel.org, alexander.shishkin@...ux.intel.com,
        andrew.kilroy@....com, benh@...nel.crashing.org,
        german.gomez@....com, james.clark@....com, john.garry@...wei.com,
        jolsa@...hat.com, 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
Subject: Re: [PATCH v2 1/2] perf arm-spe: Use SPE data source for neoverse
 cores

On Sun, Mar 13, 2022 at 07:06:19PM +0000, Ali Saidi wrote:

[...]

> > > > +static void arm_spe__synth_data_source_neoverse(const struct arm_spe_record *record,
> > > > +						union perf_mem_data_src *data_src)
> > > > +{
> > > > +	switch (record->source) {
> > > > +	case ARM_SPE_NV_L1D:
> > > > +		data_src->mem_lvl = PERF_MEM_LVL_HIT;
> > > 
> > > I understand mem_lvl is deprecated but shouldn't we add the level bits here as well for backwards compat?
> > 
> > Thanks for pointing out this.  Yeah, I think German's suggestion is
> > valid, the commit 6ae5fa61d27d ("perf/x86: Fix data source decoding
> > for Skylake") introduces new field 'mem_lvl_num', but it also keeps
> > backwards compatible for the field 'mem_lvl'.
> >
> I thought about that, but then I'm making some assumption about how to fit
> this into the old LVL framework, which is perhaps OK (afaik there are no
> Neoverse systems with more than 3 cache levels). What stopped me was that
> perf_mem__lvl_scnprintf() does the wrong thing when both are set so I
> assumed that setting both was not the right course of action.

Thanks for pointing out this.  I looked at perf_mem__lvl_scnprintf()
and it prints both for fields 'mem_lvl' and 'mem_lvl_num'.  Thus I can
see the output result shows the duplicate info for memory access like
"L1 or L1 hit", "L3 or L3 hit", etc.  This would be a common issue
crossing archs.  Do I miss any other issues?

> > > > +		data_src->mem_lvl_num = PERF_MEM_LVLNUM_L1;
> > > > +		break;
> > > > +	case ARM_SPE_NV_L2:
> > > > +		data_src->mem_lvl = PERF_MEM_LVL_HIT;
> > > > +		data_src->mem_lvl_num = PERF_MEM_LVLNUM_L2;
> > > > +		break;
> > > > +	case ARM_SPE_NV_PEER_CORE:
> > > > +		data_src->mem_lvl = PERF_MEM_LVL_HIT;
> > > > +		data_src->mem_snoop = PERF_MEM_SNOOP_HITM;
> > > > +		data_src->mem_lvl_num = PERF_MEM_LVLNUM_ANY_CACHE;
> > 
> > For PEER_CORE data source, we don't know if it's coming from peer
> > core's L1 cache or L2 cache, right?
>
> We don't.
> 
> > If so, do you think if it's possible to retrieve more accurate info
> > from the field "record->type"?
>
> No, we just don't know and it really doesn't matter. The main reason to
> understand the source is to understand the penalty of data coming from
> the source and that it's coming from a core should be sufficient.

Okay, the question is Neoverse has three different data sources
"ARM_SPE_NV_PEER_CORE", "ARM_SPE_NV_LCL_CLSTR" and
"ARM_SPE_NV_PEER_CLSTR", but the patch only uses the same attribution
for all of them.

To be honest, I don't have precise understanding the definition for
these three types, seems to me "ARM_SPE_NV_PEER_CORE" means to fetch
data cache from peer core (like SMT things), "ARM_SPE_NV_LCL_CLSTR"
means cache conherency within the same cluster with SCU,
"ARM_SPE_NV_PEER_CLSTR" means the conherency happens with external bus
(like CCI or CMN).  So I'd like to suggest to consider to extend the
level definitions so can allow us to express the data source for Arm
arch precisely.

It's important to understand current cache level definitions which is
derived from x86 arch and think what's the good way to match and
extend for Arm memory hierarchy.  I will think a bit more for this,
and if have any idea will share back.

Thanks,
Leo