linux-kernel - Re: [PATCH v6 1/7] perf vendor events arm64: Add common topdown L1 metrics

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, 9 Jan 2023 14:58:35 +0000
From:   John Garry <john.g.garry@...cle.com>
To:     Jing Zhang <renyu.zj@...ux.alibaba.com>,
        Ian Rogers <irogers@...gle.com>
Cc:     Xing Zhengjun <zhengjun.xing@...ux.intel.com>,
        Will Deacon <will@...nel.org>,
        James Clark <james.clark@....com>,
        Mike Leach <mike.leach@...aro.org>,
        Leo Yan <leo.yan@...aro.org>,
        linux-arm-kernel@...ts.infradead.org,
        linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Andrew Kilroy <andrew.kilroy@....com>,
        Shuai Xue <xueshuai@...ux.alibaba.com>,
        Zhuo Song <zhuo.song@...ux.alibaba.com>
Subject: Re: [PATCH v6 1/7] perf vendor events arm64: Add common topdown L1
 metrics

On 09/01/2023 02:53, Jing Zhang wrote:
> I'll factor out the pmu_core__find function in tools/perf/arch/arm64/util/pmu.c:
> 
> static const struct perf_pmu *pmu_core__find(void)

maybe name as pmu_core__find_same() or similar to indicate that we're 
only dealing with homogeneous cores

> {
> 	struct perf_pmu *pmu = NULL;

no need to init to NULL

> 
> 	while ((pmu = perf_pmu__scan(pmu))) {

1x superfluous level of ()

> 		if (!is_pmu_core(pmu->name))
> 			continue;
> 
> 		/*
> 		 * The cpumap should cover all CPUs. Otherwise, some CPUs may
> 		 * not support some events or have different event IDs.
> 		 */
> 		if (pmu->cpus->nr != cpu__max_cpu().cpu)
> 			return NULL;
> 		return pmu;
> 	}
> 
> 	return NULL;
> }
> 

...

> 
>>> +}
>>> diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
>>> index 69ca000..a2f7df8 100644
>>> --- a/tools/perf/util/pmu.h
>>> +++ b/tools/perf/util/pmu.h
>>> @@ -259,4 +259,5 @@ int perf_pmu__cpus_match(struct perf_pmu *pmu, struct perf_cpu_map *cpus,
>>>      char *pmu_find_real_name(const char *name);
>>>    char *pmu_find_alias_name(const char *name);
>>> +int perf_pmu__get_slots(void);
>> I think that this name is a bit too vague. Maybe perf_pmu__cpu_cycles_per_slot() could be better.
>>
> Does cpu_cycles_per_slot mean "cpu cycles per slot"? In the documemt, Slots mean operation width.
> If slots are 5, the largest value by which the STALL_SLOT PMU event may increment in one cycle is 5.
> So, maybe perf_pmu__cpu_slots_per_cycle() could be more accurate？

ok, yes, fine.

Thanks,
John