[tip: perf/urgent] perf vendor events s390: Use s390 machine name instead of type 8561
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 0d0e5ecec6116db6031829299e74cc71240c9ff3
Gitweb:
https://git.kernel.org/tip/0d0e5ecec6116db6031829299e74cc71240c9ff3
Author:Thomas Richter
AuthorDate:Fri, 27 Sep 2019 10:11:47 +02:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Mon, 30 Sep 2019 17:29:45 -03:00
perf vendor events s390: Use s390 machine name instead of type 8561
In the pmu-events directory for JSON file definitions use the
official machine name IBM z15 instead of machine type number
8561. This is consistent with previous machines.
Signed-off-by: Thomas Richter
Cc: Heiko Carstens
Cc: Vasily Gorbik
Link: http://lore.kernel.org/lkml/20190927081147.18345-2-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/pmu-events/arch/s390/cf_m8561/basic.json | 58 +-
tools/perf/pmu-events/arch/s390/cf_m8561/crypto.json | 114 +--
tools/perf/pmu-events/arch/s390/cf_m8561/crypto6.json | 30 +-
tools/perf/pmu-events/arch/s390/cf_m8561/extended.json| 373 +---
tools/perf/pmu-events/arch/s390/cf_m8561/transaction.json | 7 +-
tools/perf/pmu-events/arch/s390/cf_z15/basic.json | 58 +-
tools/perf/pmu-events/arch/s390/cf_z15/crypto.json| 114 ++-
tools/perf/pmu-events/arch/s390/cf_z15/crypto6.json | 30 +-
tools/perf/pmu-events/arch/s390/cf_z15/extended.json | 373 +++-
tools/perf/pmu-events/arch/s390/cf_z15/transaction.json | 7 +-
tools/perf/pmu-events/arch/s390/mapfile.csv | 2 +-
11 files changed, 583 insertions(+), 583 deletions(-)
delete mode 100644 tools/perf/pmu-events/arch/s390/cf_m8561/basic.json
delete mode 100644 tools/perf/pmu-events/arch/s390/cf_m8561/crypto.json
delete mode 100644 tools/perf/pmu-events/arch/s390/cf_m8561/crypto6.json
delete mode 100644 tools/perf/pmu-events/arch/s390/cf_m8561/extended.json
delete mode 100644 tools/perf/pmu-events/arch/s390/cf_m8561/transaction.json
create mode 100644 tools/perf/pmu-events/arch/s390/cf_z15/basic.json
create mode 100644 tools/perf/pmu-events/arch/s390/cf_z15/crypto.json
create mode 100644 tools/perf/pmu-events/arch/s390/cf_z15/crypto6.json
create mode 100644 tools/perf/pmu-events/arch/s390/cf_z15/extended.json
create mode 100644 tools/perf/pmu-events/arch/s390/cf_z15/transaction.json
diff --git a/tools/perf/pmu-events/arch/s390/cf_m8561/basic.json
b/tools/perf/pmu-events/arch/s390/cf_m8561/basic.json
deleted file mode 100644
index 17fb524..000
--- a/tools/perf/pmu-events/arch/s390/cf_m8561/basic.json
+++ /dev/null
@@ -1,58 +0,0 @@
-[
- {
- "Unit": "CPU-M-CF",
- "EventCode": "0",
- "EventName": "CPU_CYCLES",
- "BriefDescription": "CPU Cycles",
- "PublicDescription": "Cycle Count"
- },
- {
- "Unit": "CPU-M-CF",
- "EventCode": "1",
- "EventName": "INSTRUCTIONS",
- "BriefDescription": "Instructions",
- "PublicDescription": "Instruction Count"
- },
- {
- "Unit": "CPU-M-CF",
- "EventCode": "2",
- "EventName": "L1I_DIR_WRITES",
- "BriefDescription": "L1I Directory Writes",
- "PublicDescription": "Level-1 I-Cache Directory Write Count"
- },
- {
- "Unit": "CPU-M-CF",
- "EventCode": "3",
- "EventName": "L1I_PENALTY_CYCLES",
- "BriefDescription": "L1I Penalty Cycles",
- "PublicDescription": "Level-1 I-Cache Penalty Cycle Count"
- },
- {
- "Unit": "CPU-M-CF",
- "EventCode": "4",
- "EventName": "L1D_DIR_WRITES",
- "BriefDescription": "L1D Directory Writes",
- "PublicDescription": "Level-1 D-Cache Directory Write Count"
- },
- {
- "Unit": "CPU-M-CF",
- "EventCode": "5",
- "EventName": "L1D_PENALTY_CYCLES",
- "BriefDescription": "L1D Penalty Cycles",
- "PublicDescription": "Level-1 D-Cache Penalty Cycle Count"
- },
- {
- "Unit": "CPU-M-CF",
- "EventCode": "32",
- "EventName": "PROBLEM_STATE_CPU_CYCLES",
- "BriefDescription": "Problem-State CPU Cycles",
- "PublicDescription": "Problem-State Cycle Count"
- },
- {
- "Unit": "CPU-M-CF",
- "EventCode": "33",
- "EventName": "PROBLEM_STATE_INSTRUCTIONS",
- "BriefDescription": "Problem-State Instructions",
- "PublicDescription": "Problem-State Instruction Count"
- },
-]
diff --git a/tools/perf/pmu-events/arch/s390/cf_m8561/crypto.json
b/tools/perf/pmu-events/arch/s390/cf_m8561/crypto.json
deleted file mode 100644
index db286f1..000
--- a/tools/perf/pmu-events/arch/s390/cf_m8561/cr
[tip: perf/urgent] perf vendor events s390: Add JSON transaction for machine type 8561
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 02d084792273e8a5f1813dcad988229a45be96ea
Gitweb:
https://git.kernel.org/tip/02d084792273e8a5f1813dcad988229a45be96ea
Author:Thomas Richter
AuthorDate:Fri, 27 Sep 2019 10:11:46 +02:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Mon, 30 Sep 2019 17:29:42 -03:00
perf vendor events s390: Add JSON transaction for machine type 8561
Add s390 transaction counter definition for machine 8561. This is the
same file as for the predecessor machine.
Fixes: 6e67d77d673d ("perf vendor events s390: Add JSON files for machine type
8561")
Signed-off-by: Thomas Richter
Cc: Heiko Carstens
Cc: Vasily Gorbik
Link: http://lore.kernel.org/lkml/20190927081147.18345-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/pmu-events/arch/s390/cf_m8561/transaction.json | 7 +++-
1 file changed, 7 insertions(+)
create mode 100644 tools/perf/pmu-events/arch/s390/cf_m8561/transaction.json
diff --git a/tools/perf/pmu-events/arch/s390/cf_m8561/transaction.json
b/tools/perf/pmu-events/arch/s390/cf_m8561/transaction.json
new file mode 100644
index 000..1a0034f
--- /dev/null
+++ b/tools/perf/pmu-events/arch/s390/cf_m8561/transaction.json
@@ -0,0 +1,7 @@
+[
+ {
+"BriefDescription": "Transaction count",
+"MetricName": "transaction",
+"MetricExpr": "TX_C_TEND + TX_NC_TEND + TX_NC_TABORT + TX_C_TABORT_SPECIAL
+ TX_C_TABORT_NO_SPECIAL"
+ }
+]
[tip: perf/urgent] perf jvmti: Link against tools/lib/ctype.h to have weak strlcpy()
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 6a6fac11b11299aa5bd8532ea863fc2f652af2b6
Gitweb:
https://git.kernel.org/tip/6a6fac11b11299aa5bd8532ea863fc2f652af2b6
Author:Thomas Richter
AuthorDate:Tue, 08 Oct 2019 11:38:41 +02:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Tue, 15 Oct 2019 11:47:38 -03:00
perf jvmti: Link against tools/lib/ctype.h to have weak strlcpy()
The build of file libperf-jvmti.so succeeds but the resulting
object fails to load:
# ~/linux/tools/perf/perf record -k mono -- java \
-XX:+PreserveFramePointer \
-agentpath:/root/linux/tools/perf/libperf-jvmti.so \
hog 10 123450
Error occurred during initialization of VM
Could not find agent library /root/linux/tools/perf/libperf-jvmti.so
in absolute path, with error:
/root/linux/tools/perf/libperf-jvmti.so: undefined symbol: _ctype
Add the missing _ctype symbol into the build script.
Fixes: 79743bc927f6 ("perf jvmti: Link against tools/lib/string.o to have weak
strlcpy()")
Signed-off-by: Thomas Richter
Cc: Heiko Carstens
Cc: Vasily Gorbik
Link: http://lore.kernel.org/lkml/20191008093841.59387-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/jvmti/Build | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/perf/jvmti/Build b/tools/perf/jvmti/Build
index 1e148bb..202cada 100644
--- a/tools/perf/jvmti/Build
+++ b/tools/perf/jvmti/Build
@@ -2,7 +2,7 @@ jvmti-y += libjvmti.o
jvmti-y += jvmti_agent.o
# For strlcpy
-jvmti-y += libstring.o
+jvmti-y += libstring.o libctype.o
CFLAGS_jvmti = -fPIC -DPIC -I$(JDIR)/include -I$(JDIR)/include/linux
CFLAGS_REMOVE_jvmti = -Wmissing-declarations
@@ -15,3 +15,7 @@ CFLAGS_libstring.o += -Wno-unused-parameter
-DETC_PERFCONFIG="BUILD_STR($(ETC_PE
$(OUTPUT)jvmti/libstring.o: ../lib/string.c FORCE
$(call rule_mkdir)
$(call if_changed_dep,cc_o_c)
+
+$(OUTPUT)jvmti/libctype.o: ../lib/ctype.c FORCE
+ $(call rule_mkdir)
+ $(call if_changed_dep,cc_o_c)
[tip: perf/urgent] perf/aux: Fix tracking of auxiliary trace buffer allocation
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 5e6c3c7b1ec217c1c4c95d9148182302b9969b97
Gitweb:
https://git.kernel.org/tip/5e6c3c7b1ec217c1c4c95d9148182302b9969b97
Author:Thomas Richter
AuthorDate:Mon, 21 Oct 2019 10:33:54 +02:00
Committer: Ingo Molnar
CommitterDate: Mon, 21 Oct 2019 11:31:24 +02:00
perf/aux: Fix tracking of auxiliary trace buffer allocation
The following commit from the v5.4 merge window:
d44248a41337 ("perf/core: Rework memory accounting in perf_mmap()")
... breaks auxiliary trace buffer tracking.
If I run command 'perf record -e rbd000' to record samples and saving
them in the **auxiliary** trace buffer then the value of 'locked_vm' becomes
negative after all trace buffers have been allocated and released:
During allocation the values increase:
[52.250027] perf_mmap user->locked_vm:0x87 pinned_vm:0x0 ret:0
[52.250115] perf_mmap user->locked_vm:0x107 pinned_vm:0x0 ret:0
[52.250251] perf_mmap user->locked_vm:0x188 pinned_vm:0x0 ret:0
[52.250326] perf_mmap user->locked_vm:0x208 pinned_vm:0x0 ret:0
[52.250441] perf_mmap user->locked_vm:0x289 pinned_vm:0x0 ret:0
[52.250498] perf_mmap user->locked_vm:0x309 pinned_vm:0x0 ret:0
[52.250613] perf_mmap user->locked_vm:0x38a pinned_vm:0x0 ret:0
[52.250715] perf_mmap user->locked_vm:0x408 pinned_vm:0x2 ret:0
[52.250834] perf_mmap user->locked_vm:0x408 pinned_vm:0x83 ret:0
[52.250915] perf_mmap user->locked_vm:0x408 pinned_vm:0x103 ret:0
[52.251061] perf_mmap user->locked_vm:0x408 pinned_vm:0x184 ret:0
[52.251146] perf_mmap user->locked_vm:0x408 pinned_vm:0x204 ret:0
[52.251299] perf_mmap user->locked_vm:0x408 pinned_vm:0x285 ret:0
[52.251383] perf_mmap user->locked_vm:0x408 pinned_vm:0x305 ret:0
[52.251544] perf_mmap user->locked_vm:0x408 pinned_vm:0x386 ret:0
[52.251634] perf_mmap user->locked_vm:0x408 pinned_vm:0x406 ret:0
[52.253018] perf_mmap user->locked_vm:0x408 pinned_vm:0x487 ret:0
[52.253197] perf_mmap user->locked_vm:0x408 pinned_vm:0x508 ret:0
[52.253374] perf_mmap user->locked_vm:0x408 pinned_vm:0x589 ret:0
[52.253550] perf_mmap user->locked_vm:0x408 pinned_vm:0x60a ret:0
[52.253726] perf_mmap user->locked_vm:0x408 pinned_vm:0x68b ret:0
[52.253903] perf_mmap user->locked_vm:0x408 pinned_vm:0x70c ret:0
[52.254084] perf_mmap user->locked_vm:0x408 pinned_vm:0x78d ret:0
[52.254263] perf_mmap user->locked_vm:0x408 pinned_vm:0x80e ret:0
The value of user->locked_vm increases to a limit then the memory
is tracked by pinned_vm.
During deallocation the size is subtracted from pinned_vm until
it hits a limit. Then a larger value is subtracted from locked_vm
leading to a large number (because of type unsigned):
[64.267797] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x78d
[64.267826] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x70c
[64.267848] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x68b
[64.267869] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x60a
[64.267891] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x589
[64.267911] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x508
[64.267933] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x487
[64.267952] perf_mmap_close mmap_user->locked_vm:0x408 pinned_vm:0x406
[64.268883] perf_mmap_close mmap_user->locked_vm:0x307 pinned_vm:0x406
[64.269117] perf_mmap_close mmap_user->locked_vm:0x206 pinned_vm:0x406
[64.269433] perf_mmap_close mmap_user->locked_vm:0x105 pinned_vm:0x406
[64.269536] perf_mmap_close mmap_user->locked_vm:0x4 pinned_vm:0x404
[64.269797] perf_mmap_close mmap_user->locked_vm:0xff84
pinned_vm:0x303
[64.270105] perf_mmap_close mmap_user->locked_vm:0xff04
pinned_vm:0x202
[64.270374] perf_mmap_close mmap_user->locked_vm:0xfe84
pinned_vm:0x101
[64.270628] perf_mmap_close mmap_user->locked_vm:0xfe04
pinned_vm:0x0
This value sticks for the user until system is rebooted, causing
follow-on system calls using locked_vm resource limit to fail.
Note: There is no issue using the normal trace buffer.
In fact the issue is in perf_mmap_close(). During allocation auxiliary
trace buffer memory is either traced as 'extra' and added to 'pinned_vm'
or trace as 'user_extra' and added to 'locked_vm'. This applies for
normal trace buffers and auxiliary trace buffer.
However in function perf_mmap_close() all auxiliary trace buffer is
subtraced from 'locked_vm' and never from 'pinned_vm'. This breaks the
ballance.
Signed-off-by: Thomas Richter
Acked-by: Peter Zijlstra
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: a...@kernel.org
Cc: g...@linux.ibm.com
Cc: hech...@fb.com
Cc: heiko.carst...@de.ibm.com
Cc: linux-perf-us...@vger.kernel.org
Cc: songliubrav...@fb.com
Fixes: d44248a41337 ("perf/core: Rework memory accounting i
[tip: perf/core] perf jvmti: Link against tools/lib/ctype.h to have weak strlcpy()
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 5fb470bc29d8e2ff0e1cab4fbb580a06da11ab28
Gitweb:
https://git.kernel.org/tip/5fb470bc29d8e2ff0e1cab4fbb580a06da11ab28
Author:Thomas Richter
AuthorDate:Tue, 08 Oct 2019 11:38:41 +02:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Tue, 15 Oct 2019 08:39:42 -03:00
perf jvmti: Link against tools/lib/ctype.h to have weak strlcpy()
The build of file libperf-jvmti.so succeeds but the resulting
object fails to load:
# ~/linux/tools/perf/perf record -k mono -- java \
-XX:+PreserveFramePointer \
-agentpath:/root/linux/tools/perf/libperf-jvmti.so \
hog 10 123450
Error occurred during initialization of VM
Could not find agent library /root/linux/tools/perf/libperf-jvmti.so
in absolute path, with error:
/root/linux/tools/perf/libperf-jvmti.so: undefined symbol: _ctype
Add the missing _ctype symbol into the build script.
Fixes: 79743bc927f6 ("perf jvmti: Link against tools/lib/string.o to have weak
strlcpy()")
Signed-off-by: Thomas Richter
Cc: Heiko Carstens
Cc: Vasily Gorbik
Link: http://lore.kernel.org/lkml/20191008093841.59387-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/jvmti/Build | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/perf/jvmti/Build b/tools/perf/jvmti/Build
index 1e148bb..202cada 100644
--- a/tools/perf/jvmti/Build
+++ b/tools/perf/jvmti/Build
@@ -2,7 +2,7 @@ jvmti-y += libjvmti.o
jvmti-y += jvmti_agent.o
# For strlcpy
-jvmti-y += libstring.o
+jvmti-y += libstring.o libctype.o
CFLAGS_jvmti = -fPIC -DPIC -I$(JDIR)/include -I$(JDIR)/include/linux
CFLAGS_REMOVE_jvmti = -Wmissing-declarations
@@ -15,3 +15,7 @@ CFLAGS_libstring.o += -Wno-unused-parameter
-DETC_PERFCONFIG="BUILD_STR($(ETC_PE
$(OUTPUT)jvmti/libstring.o: ../lib/string.c FORCE
$(call rule_mkdir)
$(call if_changed_dep,cc_o_c)
+
+$(OUTPUT)jvmti/libctype.o: ../lib/ctype.c FORCE
+ $(call rule_mkdir)
+ $(call if_changed_dep,cc_o_c)
[tip: perf/core] perf symbol: Fix kernel symbol address display
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 51d9635582c55479bf7904fa47e39aef2b323a50
Gitweb:
https://git.kernel.org/tip/51d9635582c55479bf7904fa47e39aef2b323a50
Author:Thomas Richter
AuthorDate:Wed, 15 Apr 2020 09:07:44 +02:00
Committer: Arnaldo Carvalho de Melo
CommitterDate: Tue, 05 May 2020 16:35:32 -03:00
perf symbol: Fix kernel symbol address display
Running commands
./perf record -e rb -- find .
./perf report -v
reveals symbol names and its addresses. There is a mismatch between
kernel symbol and address. Here is an example for kernel symbol
check_chain_key:
3.55% find /lib/modules/.../build/vmlinux 0xf11ec v [k] check_chain_key
This address is off by 0xff000 as can be seen with:
[root@t35lp46 ~]# fgrep check_chain_key /proc/kallsyms
001f00d0 t check_chain_key
[root@t35lp46 ~]# objdump -t ~/linux/vmlinux| fgrep check_chain_key
001f00d0 l F .text 01e8 check_chain_key
[root@t35lp46 ~]#
This function is located in main memory 0x1f00d0 - 0x1f02b4. It has
several entries in the perf data file with the correct address:
[root@t35lp46 perf]# ./perf report -D -i perf.data.find-bad | \
fgrep SAMPLE| fgrep 0x1f01ec
PERF_RECORD_SAMPLE(IP, 0x1): 8/8: 0x1f01ec period: 130 addr: 0
PERF_RECORD_SAMPLE(IP, 0x1): 8/8: 0x1f01ec period: 130 addr: 0
The root cause happens when reading symbol tables during perf report.
A long gdb call chain leads to
machine__deliver_events
perf_evlist__deliver_event
perf_evlist__deliver_sample
build_id__mark_dso_hits
thread__find_map(1) Read correct address from sample entry
map__load
dso__loadSome more functions to end up in
dso__load_sym.
Function dso__load_syms checks for kernel relocation and symbol
adjustment for the kernel and results in kernel map adjustment of
kernel .text segment address (0x10 on s390)
kernel .text segment offset in file (0x1000 on s390).
This results in all kernel symbol addresses to be changed by subtracting
0xff000 (on s390). For the symbol check_chain_key we end up with
0x1f00d0 - 0x10 + 0x1000 = 0xf11d0
and this address is saved in the perf symbol table. This calculation is
also applied by the mapping functions map__mapip() and map__unmapip()
to map IP addresses to dso mappings.
During perf report processing functions
process_sample_event(builtin-report.c)
machine__resolve
thread__find_map
hist_entry_iter_add
are called. Function thread__find_map(1)
takes the correct sample address and applies the mapping function
map__mapip() from the kernel dso and saves the modified address
in struct addr_location for further reference. From now on this address
is used.
Funktion process_sample_event() then calls hist_entry_iter_add() to save
the address in member ip of struct hist_entry.
When samples are displayed using
perf_evlist__tty_browse_hists
hists__fprintf
hist_entry__fprintf
hist_entry__snprintf
__hist_entry__snprintf
_hist_entry__sym_snprintf()
This simply displays the address of the symbol and ignores the dso <-> map
mappings done in function thread__find_map. This leads to the address
mismatch.
Output before:
ot@t35lp46 perf]# ./perf report -v | fgrep check_chain_key
3.55% find /lib/modules/5.6.0d-perf+/build/vmlinux
0xf11ec v [k] check_chain_key
[root@t35lp46 perf]#
Output after:
[root@t35lp46 perf]# ./perf report -v | fgrep check_chain_key
3.55% find /lib/modules/5.6.0d-perf+/build/vmlinux
0x1f01ec v [k] check_chain_key
[root@t35lp46 perf]#
Signed-off-by: Thomas Richter
Acked-by: Sumanth Korikkar
Cc: Heiko Carstens
Cc: Vasily Gorbik
Link: http://lore.kernel.org/lkml/20200415070744.59919-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/sort.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index dc23b34..c1f8879 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -300,8 +300,14 @@ static int _hist_entry__sym_snprintf(struct map_symbol *ms,
if (verbose > 0) {
char o = map ? dso__symtab_origin(map->dso) : '!';
+ u64 rip = ip;
+
+ if (map && map->dso && map->dso->kernel
+ && map->dso->adjust_symbols)
+ rip = map->unmap_ip(map, ip);
+
ret += repsep_snprintf(bf, size, "%-#*llx %c ",
- BITS_PER_LONG / 4 + 2, ip, o);
+ BITS_PER_LONG / 4 + 2, rip, o);
}
ret += repsep_snprintf(bf + ret, size - ret, "[%c] ", le
