Messages in this thread | | | Date | Tue, 20 Jun 2023 10:12:58 +0800 | Subject | Re: [PATCH v3 2/7] perf metric: Event "Compat" value supports matching multiple identifiers | From | Jing Zhang <> |
| |
在 2023/6/19 下午5:31, John Garry 写道: > On 19/06/2023 09:59, Jing Zhang wrote: >>> 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 > > In the earlier RFC series you had tools/perf/pmu-events/arch/arm64/arm/cmn700/sys/cmn.json, which describes event hnf_slc_sf_cache_access > > But that JSON is not in this series. Why is it not included? >
Because the RFC version of the cmn.json file does not define the EventCode for each event, this will not take effect, so I temporarily removed it. The EventID of CMN events is different from other events. For example, hnf_slc_sf_cache_access corresponds to arm_cmn_0/type=0x5,eventid=0x2/. The current JSON format parsing does not support this EventID, and jevent.py needs to be extended.
> The cmn kernel driver exposes event hnf_slc_sf_cache_access, but I did not think that perf tool metric code matches those events described in /bus/event_sourcs/devices/<PMU>/events >
If there is no alias defined, other events with the same name may be matched, it is indeed necessary to define an alias for each event first, and I will add it in the next version. But first I need to extend jevent.py to support cmn EventID.
>> 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? > > In this case, yes - it would work for uncore_cbox_0/clockticks/ and uncore_cbox_1/clockticks/ > > But you need to be careful to here - if another PMU has same event name, then it might also match. >
Ok, I got it.
Thanks, Jing
> Thanks, > John
| |