Messages in this thread | | | Date | Mon, 19 Jun 2023 16:59:08 +0800 | Subject | Re: [PATCH v3 2/7] perf metric: Event "Compat" value supports matching multiple identifiers | From | Jing Zhang <> |
| |
在 2023/6/19 下午3:07, John Garry 写道: > On 19/06/2023 03:58, Jing Zhang wrote: >>> +++ b/tools/perf/pmu-events/arch/arm64/arm/cmn/sys/metrics.json >>> @@ -0,0 +1,74 @@ >>> +[ >>> + { >>> + "MetricName": "slc_miss_rate", >>> + "BriefDescription": "The system level cache miss rate include.", >>> + "MetricGroup": "arm_cmn", >>> + "MetricExpr": "hnf_cache_miss / hnf_slc_sf_cache_access", >>> >>> So this expression uses event aliases hnf_cache_miss and hnf_slc_sf_cache_access - where are they defined in a JSON? >>> >> Hi John, >> >> I defined the aliases for these events in the JSON file during the RFC version. However, I later removed the alias >> definitions for these events in subsequent versions due to the possibility of non-uniqueness and difficulty in defining >> their EventCode. But this does not affect their usage in metrics. In other words, metrics can use the aliases without >> defining event aliases in the JSON file. > > Really? So how can we resolve the event aliases when we try to run the metric? > > Please verify running these metrics with 'perf stat', like 'perf stat -v -M slc_miss_rate' >
Ok, it shows: #./perf stat -v -M slc_miss_rate sleep 1
metric expr hnf_cache_miss / hnf_slc_sf_cache_access for slc_miss_rate found event duration_time found event hnf_slc_sf_cache_access found event hnf_cache_miss Parsing metric events '{hnf_slc_sf_cache_access/metric-id=hnf_slc_sf_cache_access/,hnf_cache_miss/metric-id=hnf_cache_miss/}:W,duration_time' hnf_slc_sf_cache_access -> arm_cmn_0/type=0x5,eventid=0x2/ hnf_slc_sf_cache_access -> arm_cmn_1/type=0x5,eventid=0x2/ hnf_cache_miss -> arm_cmn_0/type=0x5,eventid=0x1/ hnf_cache_miss -> arm_cmn_1/type=0x5,eventid=0x1/ Control descriptor is not initialized hnf_slc_sf_cache_access: 127615 1001344900 1001344900 hnf_cache_miss: 36829 1001344900 1001344900 hnf_slc_sf_cache_access: 131526 1001343540 1001343540 hnf_cache_miss: 40587 1001343540 1001343540 duration_time: 1001381687 1001381687 1001381687
Performance counter stats for 'system wide':
259,141 hnf_slc_sf_cache_access # 29.9 % slc_miss_rate 77,416 hnf_cache_miss 1,001,381,687 ns duration_time
1.001381687 seconds time elapsed
#./perf list ... arm_cmn_0/hnf_cache_miss/ [Kernel PMU event] arm_cmn_0/hnf_slc_sf_cache_access/ [Kernel PMU event] ... arm_cmn_1/hnf_cache_miss/ [Kernel PMU event] arm_cmn_1/hnf_slc_sf_cache_access/ [Kernel PMU event] ...
>> >> In the past, I always thought that the function of the alias was to explain the meaning of these events in the perf list. >> Or maybe I'm missing something? > > Event aliases do give the ability to describe the event in perf list. But we can also run them for 'perf stat', like: > > ./perf list uncore > List of pre-defined events (to be used in -e or -M): > > uncore_cbox_0/clockticks/ [Kernel PMU event] > uncore_cbox_1/clockticks/ [Kernel PMU event] > uncore_imc/data_reads/ [Kernel PMU event] > uncore_imc/data_writes/ [Kernel PMU event] > uncore_imc/gt_requests/ [Kernel PMU event] > uncore_imc/ia_requests/ [Kernel PMU event] > uncore_imc/io_requests/ [Kernel PMU event] > > uncore cache: > unc_cbo_cache_lookup.any_es > [L3 Lookup any request that access cache and found line in E or S-state. Unit: uncore_cbox] > ... > > sudo ./perf stat -v -e unc_cbo_cache_lookup.any_es > Using CPUID GenuineIntel-6-3D-4 > unc_cbo_cache_lookup.any_es -> uncore_cbox_0/event=0x34,umask=0x86/ > unc_cbo_cache_lookup.any_es -> uncore_cbox_1/event=0x34,umask=0x86/ > Control descriptor is not initialized > ^Cunc_cbo_cache_lookup.any_es: 14361103 1853372468 1853372468 > unc_cbo_cache_lookup.any_es: 14322188 1853360415 1853360415 > > Performance counter stats for 'system wide': > > 14,361,103 unc_cbo_cache_lookup.any_es > 14,322,188 unc_cbo_cache_lookup.any_es > > 1.853388227 seconds time elapsed >
Ok, thanks. If I use events without a prefix, such as perf stat -e clockticks sleep 1, will this also work?
Thanks, Jing
> > Thanks, > John
| |