In 7fcfa9a2d9 an unintended prefix "Counter:18 Name:" was removed from
the description for L1D_RO_EXCL_WRITES, but the extra name remained in
the description. Remove it too.
Fixes: 7fcfa9a2d9a7 ("perf list: Fix s390 counter long description for L1D_RO_EXCL_WRITES")
Signed-off-by: Ed Maste <emaste@freebsd.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Nick Hu <nickhu@andestech.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Richter <tmricht@linux.ibm.com>
Cc: Vincent Chen <deanbo422@gmail.com>
Link: http://lore.kernel.org/lkml/20191212145346.5026-1-emaste@freefall.freebsd.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The cf_z13 counter DTLB1_GPAGE_WRITES included a prefix 'Counter:132\tName:'. This is incorrect; remove the prefix as with 7fcfa9a2d9 for cf_z14. Signed-off-by: Ed Maste <emaste@freebsd.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Greentime Hu <green.hu@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Nick Hu <nickhu@andestech.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Richter <tmricht@linux.ibm.com> Cc: Vincent Chen <deanbo422@gmail.com> Link: http://lore.kernel.org/lkml/20191212143446.88582-1-emaste@freefall.freebsd.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Before this patch, perf expected that there might be NPROC*4 unique cache entries at max, however, it also expected that some of them would be shared and/or of the same size, thus the final number of entries would be reduced to be lower than NPROC*4. In case the number of entries hadn't been reduced (was NPROC*4), the warning was printed. However, some systems might have unusual cache topology, such as the following two-processor KVM guest: cpu level shared_cpu_list size 0 1 0 32K 0 1 0 64K 0 2 0 512K 0 3 0 8192K 1 1 1 32K 1 1 1 64K 1 2 1 512K 1 3 1 8192K This KVM guest has 8 (NPROC*4) unique cache entries, which used to make perf printing the message, although there actually aren't "way too many cpu caches". v2: Removing unused argument. v3: Unifying the way we obtain number of cpus. v4: Removed '& UINT_MAX' construct which is redundant. Signed-off-by: Michael Petlan <mpetlan@redhat.com> Acked-by: Jiri Olsa <jolsa@redhat.com> LPU-Reference: 20191208162056.20772-1-mpetlan@redhat.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Commit f01642e4912b ("perf metricgroup: Support multiple events for
metricgroup") introduced support for multiple events in a metric group.
But with the current upstream, metric events names are not printed
properly
In power9 platform:
command:# ./perf stat --metric-only -M translation -C 0 -I 1000 sleep 2
1.000208486
2.000368863
2.001400558
Similarly in skylake platform:
command:./perf stat --metric-only -M Power -I 1000
1.000579994
2.002189493
With current upstream version, issue is with event name comparison logic
in find_evsel_group(). Current logic is to compare events belonging to a
metric group to the events in perf_evlist. Since the break statement is
missing in the loop used for comparison between metric group and
perf_evlist events, the loop continues to execute even after getting a
pattern match, and end up in discarding the matches.
Incase of single metric event belongs to metric group, its working fine,
because in case of single event once it compare all events it reaches to
end of perf_evlist.
Example for single metric event in power9 platform:
command:# ./perf stat --metric-only -M branches_per_inst -I 1000 sleep 1
1.000094653 0.2
1.001337059 0.0
This patch fixes the issue by making sure once we found all events
belongs to that metric event matched in find_evsel_group(), we
successfully break from that loop by adding corresponding condition.
With this patch:
In power9 platform:
command:# ./perf stat --metric-only -M translation -C 0 -I 1000 sleep 2
result:#
time derat_4k_miss_rate_percent derat_4k_miss_ratio derat_miss_ratio derat_64k_miss_rate_percent derat_64k_miss_ratio dslb_miss_rate_percent islb_miss_rate_percent
1.000135672 0.0 0.3 1.0 0.0 0.2 0.0 0.0
2.000380617 0.0 0.0 0.0 0.0 0.0 0.0 0.0
command:# ./perf stat --metric-only -M Power -I 1000
Similarly in skylake platform:
result:#
time Turbo_Utilization C3_Core_Residency C6_Core_Residency C7_Core_Residency C2_Pkg_Residency C3_Pkg_Residency C6_Pkg_Residency C7_Pkg_Residency
1.000563580 0.3 0.0 2.6 44.2 21.9 0.0 0.0 0.0
2.002235027 0.4 0.0 2.7 43.0 20.7 0.0 0.0 0.0
Committer testing:
Before:
[root@seventh ~]# perf stat --metric-only -M Power -I 1000
# time
1.000383223
2.001168182
3.001968545
4.002741200
5.003442022
^C 5.777687244
[root@seventh ~]#
After the patch:
[root@seventh ~]# perf stat --metric-only -M Power -I 1000
# time Turbo_Utilization C3_Core_Residency C6_Core_Residency C7_Core_Residency C2_Pkg_Residency C3_Pkg_Residency C6_Pkg_Residency C7_Pkg_Residency
1.000406577 0.4 0.1 1.4 97.0 0.0 0.0 0.0 0.0
2.001481572 0.3 0.0 0.6 97.9 0.0 0.0 0.0 0.0
3.002332585 0.2 0.0 1.0 97.5 0.0 0.0 0.0 0.0
4.003196624 0.2 0.0 0.3 98.6 0.0 0.0 0.0 0.0
5.004063851 0.3 0.0 0.7 97.7 0.0 0.0 0.0 0.0
^C 5.471260276 0.2 0.0 0.5 49.3 0.0 0.0 0.0 0.0
[root@seventh ~]#
[root@seventh ~]# dmesg | grep -i skylake
[ 0.187807] Performance Events: PEBS fmt3+, Skylake events, 32-deep LBR, full-width counters, Intel PMU driver.
[root@seventh ~]#
Fixes: f01642e4912b ("perf metricgroup: Support multiple events for metricgroup")
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
Reviewed-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Cc: Jin Yao <yao.jin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20191120084059.24458-1-kjain@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Kernel Utilization should divide ref cycles spent in kernel with total ref cycles. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Reviewed-by: Andi Kleen <ak@linux.intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Haiyan Song <haiyanx.song@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lore.kernel.org/lkml/20191204162121.29998-1-ravi.bangoria@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
'perf top' stopped working on hw architectures that do not provide a
get_cpuid() implementation and thus fallback to the weak get_cpuid()
default function.
This is done because at annotation time we may need it in the arch
specific annotation init routine, but that is only being used by arches
that do provide a get_cpuid() implementation:
$ find tools/ -name "*.[ch]" | xargs grep 'evlist->env'
tools/perf/builtin-top.c: top.evlist->env = &perf_env;
tools/perf/util/evsel.c: return evsel->evlist->env;
tools/perf/util/s390-cpumsf.c: sf->machine_type = s390_cpumsf_get_type(session->evlist->env->cpuid);
tools/perf/util/header.c: session->evlist->env = &header->env;
tools/perf/util/sample-raw.c: const char *arch_pf = perf_env__arch(evlist->env);
$
$ find tools/perf/arch -name "*.[ch]" | xargs grep -w get_cpuid
tools/perf/arch/x86/util/auxtrace.c: ret = get_cpuid(buffer, sizeof(buffer));
tools/perf/arch/x86/util/header.c:get_cpuid(char *buffer, size_t sz)
tools/perf/arch/powerpc/util/header.c:get_cpuid(char *buffer, size_t sz)
tools/perf/arch/s390/util/header.c: * Implementation of get_cpuid().
tools/perf/arch/s390/util/header.c:int get_cpuid(char *buffer, size_t sz)
tools/perf/arch/s390/util/header.c: if (buf && get_cpuid(buf, 128))
$
For 'report' or 'script', i.e. tools working on perf.data files, that is
setup while reading the header, its just top that needs to explicitely
read it at tool start.
Fixes: 608127f73779 ("perf top: Initialize perf_env->cpuid, needed by the per arch annotation init routine")
Reported-by: John Garry <john.garry@huawei.com>
Analysed-by: Jiri Olsa <jolsa@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: John Garry <john.garry@huawei.com> # arm64
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Will Deacon <will@kernel.org>
Link: https://lkml.kernel.org/n/tip-lxwjr0cd2eggzx04a780ffrv@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Some of the functions calling get_cpuid() propagate back the error it returns, and all are using errno (positive) values, make the weak default get_cpuid() function return ENOSYS to be consistent and to allow checking if this is an arch not providing this function or if a provided one is having trouble getting the cpuid, to decide if the warning should be provided to the user or just a debug message should be emitted. Reviewed-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Tested-by: John Garry <john.garry@huawei.com> # arm64 Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Will Deacon <will@kernel.org> Link: https://lkml.kernel.org/n/tip-lxwjr0cd2eggzx04a780ffrv@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To pick up BPF fixes to allow a clean 'make -C tools/perf build-test': 7c3977d1e804 libbpf: Fix sym->st_value print on 32-bit arches 1fd450f99272 libbpf: Fix up generation of bpf_helper_defs.h Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The ID index event is used when decoding, but can result in the
following error:
$ perf record --aux-sample -e '{intel_pt//,branch-misses}:u' ls
$ perf inject -i perf.data -o perf.data.inj --itrace=be
$ perf script -i perf.data.inj
0x1020 [0x410]: failed to process type: 69 [No such file or directory]
Fix by having 'perf inject' drop the ID index event.
Fixes: c0a6de06c446 ("perf record: Add support for AUX area sampling")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lore.kernel.org/lkml/20191204120800.8138-1-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
If perf.data is recorded without -d, don't allow user to use --mem-mode
with 'perf report'. symbol_daddr and phys_daddr can be recorded
separately and may be present in the perf.data but at the report time
they are associated with mem-mode fields and thus this restriction
applies to them as well.
Before:
$ perf record ls
$ perf report --mem-mode --stdio
# Overhead Local Weight Memory access Symbol
# ........ ............ ............. .......................
55.56% 0 N/A [k] 0xffffffff81a00ae7
After:
$ perf report --mem-mode --stdio
Error:
Selected --mem-mode but no mem data. Did you call perf record without -d?
Suggested-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jin Yao <yao.jin@linux.intel.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/20191114132213.5419-4-ravi.bangoria@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>