* [PATCH 01/11] tools arch uapi: Sync the x86 kvm.h copy
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
@ 2018-10-17 22:54 ` Arnaldo Carvalho de Melo
2018-10-17 22:54 ` [PATCH 02/11] tools headers uapi: Sync " Arnaldo Carvalho de Melo
` (10 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Arnaldo Carvalho de Melo @ 2018-10-17 22:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users,
Arnaldo Carvalho de Melo, Adrian Hunter, David Ahern, Jiri Olsa,
Namhyung Kim, Paolo Bonzini, Vitaly Kuznetsov, Wang Nan
From: Arnaldo Carvalho de Melo <acme@redhat.com>
To get the changes in:
d1766202779e ("x86/kvm/lapic: always disable MMIO interface in x2APIC mode")
That at this time will not generate changes in tools such as 'perf trace',
that still needs more work in tools/perf/examples/bpf/augmented_syscalls.c
to need such id -> string tables.
This silences the following perf build warning:
Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/kvm.h' differs from latest version at 'arch/x86/include/uapi/asm/kvm.h'
diff -u tools/arch/x86/include/uapi/asm/kvm.h arch/x86/include/uapi/asm/kvm.h
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: https://lkml.kernel.org/n/tip-yadntj2ok6zpzjwi656onuh0@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/arch/x86/include/uapi/asm/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/arch/x86/include/uapi/asm/kvm.h b/tools/arch/x86/include/uapi/asm/kvm.h
index 86299efa804a..fd23d5778ea1 100644
--- a/tools/arch/x86/include/uapi/asm/kvm.h
+++ b/tools/arch/x86/include/uapi/asm/kvm.h
@@ -377,6 +377,7 @@ struct kvm_sync_regs {
#define KVM_X86_QUIRK_LINT0_REENABLED (1 << 0)
#define KVM_X86_QUIRK_CD_NW_CLEARED (1 << 1)
+#define KVM_X86_QUIRK_LAPIC_MMIO_HOLE (1 << 2)
#define KVM_STATE_NESTED_GUEST_MODE 0x00000001
#define KVM_STATE_NESTED_RUN_PENDING 0x00000002
--
2.14.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 02/11] tools headers uapi: Sync kvm.h copy
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
2018-10-17 22:54 ` [PATCH 01/11] tools arch uapi: Sync the x86 kvm.h copy Arnaldo Carvalho de Melo
@ 2018-10-17 22:54 ` Arnaldo Carvalho de Melo
2018-10-17 22:54 ` [PATCH 03/11] Revert "perf tools: Fix PMU term format max value calculation" Arnaldo Carvalho de Melo
` (9 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Arnaldo Carvalho de Melo @ 2018-10-17 22:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users,
Arnaldo Carvalho de Melo, Adrian Hunter, David Ahern,
Drew Schmitt, Jiri Olsa, Namhyung Kim, Paolo Bonzini, Wang Nan
From: Arnaldo Carvalho de Melo <acme@redhat.com>
To pick up the changes introduced in:
6fbbde9a1969 ("KVM: x86: Control guest reads of MSR_PLATFORM_INFO")
That is not yet used in tools such as 'perf trace'.
The type of the change in this file, a simple integer parameter to the
KVM_CHECK_EXTENSION ioctl should be easier to implement tho, adding to
the libbeauty TODO list.
This silences this perf build warning:
Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from latest version at 'include/uapi/linux/kvm.h'
diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Drew Schmitt <dasch@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: https://lkml.kernel.org/n/tip-67h1bio5bihi1q6dy7hgwwx8@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/include/uapi/linux/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/include/uapi/linux/kvm.h b/tools/include/uapi/linux/kvm.h
index 07548de5c988..251be353f950 100644
--- a/tools/include/uapi/linux/kvm.h
+++ b/tools/include/uapi/linux/kvm.h
@@ -952,6 +952,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_S390_HPAGE_1M 156
#define KVM_CAP_NESTED_STATE 157
#define KVM_CAP_ARM_INJECT_SERROR_ESR 158
+#define KVM_CAP_MSR_PLATFORM_INFO 159
#ifdef KVM_CAP_IRQ_ROUTING
--
2.14.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 03/11] Revert "perf tools: Fix PMU term format max value calculation"
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
2018-10-17 22:54 ` [PATCH 01/11] tools arch uapi: Sync the x86 kvm.h copy Arnaldo Carvalho de Melo
2018-10-17 22:54 ` [PATCH 02/11] tools headers uapi: Sync " Arnaldo Carvalho de Melo
@ 2018-10-17 22:54 ` Arnaldo Carvalho de Melo
2018-10-17 22:54 ` [PATCH 04/11] perf vendor events intel: Fix wrong filter_band* values for uncore events Arnaldo Carvalho de Melo
` (8 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Arnaldo Carvalho de Melo @ 2018-10-17 22:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users, Jiri Olsa,
Alexander Shishkin, Andi Kleen, Kan Liang, Namhyung Kim,
Peter Zijlstra, Arnaldo Carvalho de Melo
From: Jiri Olsa <jolsa@kernel.org>
This reverts commit ac0e2cd555373ae6f8f3a3ad3fbbf5b6d1e7aaaa.
Michael reported an issue with oversized terms values assignment
and I noticed there was actually a misunderstanding of the max
value check in the past.
The above commit's changelog says:
If bit 21 is set, there is parsing issues as below.
$ perf stat -a -e uncore_qpi_0/event=0x200002,umask=0x8/
event syntax error: '..pi_0/event=0x200002,umask=0x8/'
\___ value too big for format, maximum is 511
But there's no issue there, because the event value is distributed
along the value defined by the format. Even if the format defines
separated bit, the value is treated as a continual number, which
should follow the format definition.
In above case it's 9-bit value with last bit separated:
$ cat uncore_qpi_0/format/event
config:0-7,21
Hence the value 0x200002 is correctly reported as format violation,
because it exceeds 9 bits. It should have been 0x102 instead, which
sets the 9th bit - the bit 21 of the format.
$ perf stat -vv -a -e uncore_qpi_0/event=0x102,umask=0x8/
Using CPUID GenuineIntel-6-2D
...
------------------------------------------------------------
perf_event_attr:
type 10
size 112
config 0x200802
sample_type IDENTIFIER
...
Reported-by: Michael Petlan <mpetlan@redhat.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Fixes: ac0e2cd55537 ("perf tools: Fix PMU term format max value calculation")
Link: http://lkml.kernel.org/r/20181003072046.29276-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/pmu.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index afd68524ffa9..7799788f662f 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -930,13 +930,14 @@ static void pmu_format_value(unsigned long *format, __u64 value, __u64 *v,
static __u64 pmu_format_max_value(const unsigned long *format)
{
- __u64 w = 0;
- int fbit;
-
- for_each_set_bit(fbit, format, PERF_PMU_FORMAT_BITS)
- w |= (1ULL << fbit);
+ int w;
- return w;
+ w = bitmap_weight(format, PERF_PMU_FORMAT_BITS);
+ if (!w)
+ return 0;
+ if (w < 64)
+ return (1ULL << w) - 1;
+ return -1;
}
/*
--
2.14.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 04/11] perf vendor events intel: Fix wrong filter_band* values for uncore events
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
` (2 preceding siblings ...)
2018-10-17 22:54 ` [PATCH 03/11] Revert "perf tools: Fix PMU term format max value calculation" Arnaldo Carvalho de Melo
@ 2018-10-17 22:54 ` Arnaldo Carvalho de Melo
2018-10-17 22:54 ` [PATCH 05/11] perf evsel: Store ids for events with their own cpus perf_event__synthesize_event_update_cpus Arnaldo Carvalho de Melo
` (7 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Arnaldo Carvalho de Melo @ 2018-10-17 22:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users, Jiri Olsa,
Jiri Olsa, Alexander Shishkin, Kan Liang, Namhyung Kim,
Peter Zijlstra, Arnaldo Carvalho de Melo
From: Jiri Olsa <jolsa@redhat.com>
Michael reported that he could not stat following event:
$ perf stat -e unc_p_freq_ge_1200mhz_cycles -a -- ls
event syntax error: '..e_1200mhz_cycles'
\___ value too big for format, maximum is 255
Run 'perf list' for a list of valid events
The event is unwrapped into:
uncore_pcu/event=0xb,filter_band0=1200/
where filter_band0 format says it's one byte only:
# cat uncore_pcu/format/filter_band0
config1:0-7
while JSON files specifies bigger number:
"Filter": "filter_band0=1200",
all the filter_band* formats show 1 byte width:
# cat uncore_pcu/format/filter_band1
config1:8-15
# cat uncore_pcu/format/filter_band2
config1:16-23
# cat uncore_pcu/format/filter_band3
config1:24-31
The reason of the issue is that filter_band* values are supposed to be
in 100Mhz units.. it's stated in the JSON help for the events, like:
filter_band3=XXX, with XXX in 100Mhz units
This patch divides the filter_band* values by 100, plus there's couple
of changes that actually change the number completely, like:
- "Filter": "edge=1,filter_band2=4000",
+ "Filter": "edge=1,filter_band2=30",
Reported-by: Michael Petlan <mpetlan@redhat.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Andi Kleen <ak@linux.intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20181010080339.GB15790@krava
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/pmu-events/arch/x86/ivytown/uncore-power.json | 16 ++++++++--------
.../perf/pmu-events/arch/x86/jaketown/uncore-power.json | 16 ++++++++--------
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/tools/perf/pmu-events/arch/x86/ivytown/uncore-power.json b/tools/perf/pmu-events/arch/x86/ivytown/uncore-power.json
index d40498f2cb1e..635c09fda1d9 100644
--- a/tools/perf/pmu-events/arch/x86/ivytown/uncore-power.json
+++ b/tools/perf/pmu-events/arch/x86/ivytown/uncore-power.json
@@ -188,7 +188,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xb",
"EventName": "UNC_P_FREQ_GE_1200MHZ_CYCLES",
- "Filter": "filter_band0=1200",
+ "Filter": "filter_band0=12",
"MetricExpr": "(UNC_P_FREQ_GE_1200MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_1200mhz_cycles %",
"PerPkg": "1",
@@ -199,7 +199,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xc",
"EventName": "UNC_P_FREQ_GE_2000MHZ_CYCLES",
- "Filter": "filter_band1=2000",
+ "Filter": "filter_band1=20",
"MetricExpr": "(UNC_P_FREQ_GE_2000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_2000mhz_cycles %",
"PerPkg": "1",
@@ -210,7 +210,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xd",
"EventName": "UNC_P_FREQ_GE_3000MHZ_CYCLES",
- "Filter": "filter_band2=3000",
+ "Filter": "filter_band2=30",
"MetricExpr": "(UNC_P_FREQ_GE_3000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_3000mhz_cycles %",
"PerPkg": "1",
@@ -221,7 +221,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xe",
"EventName": "UNC_P_FREQ_GE_4000MHZ_CYCLES",
- "Filter": "filter_band3=4000",
+ "Filter": "filter_band3=40",
"MetricExpr": "(UNC_P_FREQ_GE_4000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_4000mhz_cycles %",
"PerPkg": "1",
@@ -232,7 +232,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xb",
"EventName": "UNC_P_FREQ_GE_1200MHZ_TRANSITIONS",
- "Filter": "edge=1,filter_band0=1200",
+ "Filter": "edge=1,filter_band0=12",
"MetricExpr": "(UNC_P_FREQ_GE_1200MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_1200mhz_cycles %",
"PerPkg": "1",
@@ -243,7 +243,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xc",
"EventName": "UNC_P_FREQ_GE_2000MHZ_TRANSITIONS",
- "Filter": "edge=1,filter_band1=2000",
+ "Filter": "edge=1,filter_band1=20",
"MetricExpr": "(UNC_P_FREQ_GE_2000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_2000mhz_cycles %",
"PerPkg": "1",
@@ -254,7 +254,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xd",
"EventName": "UNC_P_FREQ_GE_3000MHZ_TRANSITIONS",
- "Filter": "edge=1,filter_band2=4000",
+ "Filter": "edge=1,filter_band2=30",
"MetricExpr": "(UNC_P_FREQ_GE_3000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_3000mhz_cycles %",
"PerPkg": "1",
@@ -265,7 +265,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xe",
"EventName": "UNC_P_FREQ_GE_4000MHZ_TRANSITIONS",
- "Filter": "edge=1,filter_band3=4000",
+ "Filter": "edge=1,filter_band3=40",
"MetricExpr": "(UNC_P_FREQ_GE_4000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_4000mhz_cycles %",
"PerPkg": "1",
diff --git a/tools/perf/pmu-events/arch/x86/jaketown/uncore-power.json b/tools/perf/pmu-events/arch/x86/jaketown/uncore-power.json
index 16034bfd06dd..8755693d86c6 100644
--- a/tools/perf/pmu-events/arch/x86/jaketown/uncore-power.json
+++ b/tools/perf/pmu-events/arch/x86/jaketown/uncore-power.json
@@ -187,7 +187,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xb",
"EventName": "UNC_P_FREQ_GE_1200MHZ_CYCLES",
- "Filter": "filter_band0=1200",
+ "Filter": "filter_band0=12",
"MetricExpr": "(UNC_P_FREQ_GE_1200MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_1200mhz_cycles %",
"PerPkg": "1",
@@ -198,7 +198,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xc",
"EventName": "UNC_P_FREQ_GE_2000MHZ_CYCLES",
- "Filter": "filter_band1=2000",
+ "Filter": "filter_band1=20",
"MetricExpr": "(UNC_P_FREQ_GE_2000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_2000mhz_cycles %",
"PerPkg": "1",
@@ -209,7 +209,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xd",
"EventName": "UNC_P_FREQ_GE_3000MHZ_CYCLES",
- "Filter": "filter_band2=3000",
+ "Filter": "filter_band2=30",
"MetricExpr": "(UNC_P_FREQ_GE_3000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_3000mhz_cycles %",
"PerPkg": "1",
@@ -220,7 +220,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xe",
"EventName": "UNC_P_FREQ_GE_4000MHZ_CYCLES",
- "Filter": "filter_band3=4000",
+ "Filter": "filter_band3=40",
"MetricExpr": "(UNC_P_FREQ_GE_4000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_4000mhz_cycles %",
"PerPkg": "1",
@@ -231,7 +231,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xb",
"EventName": "UNC_P_FREQ_GE_1200MHZ_TRANSITIONS",
- "Filter": "edge=1,filter_band0=1200",
+ "Filter": "edge=1,filter_band0=12",
"MetricExpr": "(UNC_P_FREQ_GE_1200MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_1200mhz_cycles %",
"PerPkg": "1",
@@ -242,7 +242,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xc",
"EventName": "UNC_P_FREQ_GE_2000MHZ_TRANSITIONS",
- "Filter": "edge=1,filter_band1=2000",
+ "Filter": "edge=1,filter_band1=20",
"MetricExpr": "(UNC_P_FREQ_GE_2000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_2000mhz_cycles %",
"PerPkg": "1",
@@ -253,7 +253,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xd",
"EventName": "UNC_P_FREQ_GE_3000MHZ_TRANSITIONS",
- "Filter": "edge=1,filter_band2=4000",
+ "Filter": "edge=1,filter_band2=30",
"MetricExpr": "(UNC_P_FREQ_GE_3000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_3000mhz_cycles %",
"PerPkg": "1",
@@ -264,7 +264,7 @@
"Counter": "0,1,2,3",
"EventCode": "0xe",
"EventName": "UNC_P_FREQ_GE_4000MHZ_TRANSITIONS",
- "Filter": "edge=1,filter_band3=4000",
+ "Filter": "edge=1,filter_band3=40",
"MetricExpr": "(UNC_P_FREQ_GE_4000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.",
"MetricName": "freq_ge_4000mhz_cycles %",
"PerPkg": "1",
--
2.14.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 05/11] perf evsel: Store ids for events with their own cpus perf_event__synthesize_event_update_cpus
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
` (3 preceding siblings ...)
2018-10-17 22:54 ` [PATCH 04/11] perf vendor events intel: Fix wrong filter_band* values for uncore events Arnaldo Carvalho de Melo
@ 2018-10-17 22:54 ` Arnaldo Carvalho de Melo
2018-10-17 22:54 ` [PATCH 06/11] perf tools: Fix use of alternatives to find JDIR Arnaldo Carvalho de Melo
` (6 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Arnaldo Carvalho de Melo @ 2018-10-17 22:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users, Jiri Olsa,
Jiri Olsa, Alexander Shishkin, Andi Kleen, Mark Rutland,
Namhyung Kim, Peter Zijlstra, Will Deacon, linux-arm-kernel,
linuxarm, Arnaldo Carvalho de Melo
From: Jiri Olsa <jolsa@redhat.com>
John reported crash when recording on an event under PMU with cpumask defined:
root@localhost:~# ./perf_debug_ record -e armv8_pmuv3_0/br_mis_pred/ sleep 1
perf: Segmentation fault
Obtained 9 stack frames.
./perf_debug_() [0x4c5ef8]
[0xffff82ba267c]
./perf_debug_() [0x4bc5a8]
./perf_debug_() [0x419550]
./perf_debug_() [0x41a928]
./perf_debug_() [0x472f58]
./perf_debug_() [0x473210]
./perf_debug_() [0x4070f4]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe0) [0xffff8294c8a0]
Segmentation fault (core dumped)
We synthesize an update event that needs to touch the evsel id array, which is
not defined at that time. Fixing this by forcing the id allocation for events
with their own cpus.
Reported-by: John Garry <john.garry@huawei.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: John Garry <john.garry@huawei.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxarm@huawei.com
Fixes: bfd8f72c2778 ("perf record: Synthesize unit/scale/... in event update")
Link: http://lkml.kernel.org/r/20181003212052.GA32371@krava
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/builtin-report.c | 1 +
tools/perf/util/evsel.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 76e12bcd1765..b2188e623e22 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -981,6 +981,7 @@ int cmd_report(int argc, const char **argv)
.id_index = perf_event__process_id_index,
.auxtrace_info = perf_event__process_auxtrace_info,
.auxtrace = perf_event__process_auxtrace,
+ .event_update = perf_event__process_event_update,
.feature = process_feature_event,
.ordered_events = true,
.ordering_requires_timestamps = true,
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 1a61628a1c12..e596ae358c4d 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1089,6 +1089,9 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts,
attr->exclude_user = 1;
}
+ if (evsel->own_cpus)
+ evsel->attr.read_format |= PERF_FORMAT_ID;
+
/*
* Apply event specific term settings,
* it overloads any global configuration.
--
2.14.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 06/11] perf tools: Fix use of alternatives to find JDIR
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
` (4 preceding siblings ...)
2018-10-17 22:54 ` [PATCH 05/11] perf evsel: Store ids for events with their own cpus perf_event__synthesize_event_update_cpus Arnaldo Carvalho de Melo
@ 2018-10-17 22:54 ` Arnaldo Carvalho de Melo
2018-10-17 22:54 ` [PATCH 07/11] perf tools: Fix tracing_path_mount proper path Arnaldo Carvalho de Melo
` (5 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Arnaldo Carvalho de Melo @ 2018-10-17 22:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users, Jarod Wilson,
Alexander Shishkin, Namhyung Kim, Peter Zijlstra,
Stephane Eranian, William Cohen, Arnaldo Carvalho de Melo
From: Jarod Wilson <jarod@redhat.com>
When a build is run from something like a cron job, the user's $PATH is
rather minimal, of note, not including /usr/sbin in my own case. Because
of that, an automated rpm package build ultimately fails to find
libperf-jvmti.so, because somewhere within the build, this happens...
/bin/sh: alternatives: command not found
/bin/sh: alternatives: command not found
Makefile.config:849: No openjdk development package found, please install
JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
...and while the build continues, libperf-jvmti.so isn't built, and
things fall down when rpm tries to find all the %files specified. Exact
same system builds everything just fine when the job is launched from a
login shell instead of a cron job, since alternatives is in $PATH, so
openjdk is actually found.
The test required to get into this section of code actually specifies
the full path, as does a block just above it, so let's do that here too.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: William Cohen <wcohen@redhat.com>
Fixes: d4dfdf00d43e ("perf jvmti: Plug compilation into perf build")
Link: http://lkml.kernel.org/r/20180906221812.11167-1-jarod@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/Makefile.config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index f6d1a03c7523..e30d20fb482d 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -833,7 +833,7 @@ ifndef NO_JVMTI
JDIR=$(shell /usr/sbin/update-java-alternatives -l | head -1 | awk '{print $$3}')
else
ifneq (,$(wildcard /usr/sbin/alternatives))
- JDIR=$(shell alternatives --display java | tail -1 | cut -d' ' -f 5 | sed 's%/jre/bin/java.%%g')
+ JDIR=$(shell /usr/sbin/alternatives --display java | tail -1 | cut -d' ' -f 5 | sed 's%/jre/bin/java.%%g')
endif
endif
ifndef JDIR
--
2.14.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 07/11] perf tools: Fix tracing_path_mount proper path
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
` (5 preceding siblings ...)
2018-10-17 22:54 ` [PATCH 06/11] perf tools: Fix use of alternatives to find JDIR Arnaldo Carvalho de Melo
@ 2018-10-17 22:54 ` Arnaldo Carvalho de Melo
2018-10-17 22:54 ` [PATCH 08/11] perf cpu_map: Align cpu map synthesized events properly Arnaldo Carvalho de Melo
` (4 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Arnaldo Carvalho de Melo @ 2018-10-17 22:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users, Jiri Olsa,
Alexander Shishkin, Michael Petlan, Namhyung Kim, Peter Zijlstra,
Steven Rostedt, Arnaldo Carvalho de Melo
From: Jiri Olsa <jolsa@kernel.org>
If there's no tracefs (RHEL7) support the tracing_path_mount
returns debugfs path which results in following fail:
# perf probe sys_write
kprobe_events file does not exist - please rebuild kernel with CONFIG_KPROBE_EVENTS.
Error: Failed to add events.
In tracing_path_debugfs_mount function we need to return the
'tracing' path instead of just the mount to make it work:
# perf probe sys_write
Added new event:
probe:sys_write (on sys_write)
You can now use it in all perf tools, such as:
perf record -e probe:sys_write -aR sleep 1
Adding the 'return tracing_path;' also to tracing_path_tracefs_mount
function just for consistency with tracing_path_debugfs_mount.
Upstream keeps working, because it has the tracefs support.
Link: http://lkml.kernel.org/n/tip-yiwkzexq9fk1ey1xg3gnjlw4@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Fixes: 23773ca18b39 ("perf tools: Make perf aware of tracefs")
Link: http://lkml.kernel.org/r/20181016114818.3595-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/lib/api/fs/tracing_path.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/lib/api/fs/tracing_path.c b/tools/lib/api/fs/tracing_path.c
index 120037496f77..5afb11b30fca 100644
--- a/tools/lib/api/fs/tracing_path.c
+++ b/tools/lib/api/fs/tracing_path.c
@@ -36,7 +36,7 @@ static const char *tracing_path_tracefs_mount(void)
__tracing_path_set("", mnt);
- return mnt;
+ return tracing_path;
}
static const char *tracing_path_debugfs_mount(void)
@@ -49,7 +49,7 @@ static const char *tracing_path_debugfs_mount(void)
__tracing_path_set("tracing/", mnt);
- return mnt;
+ return tracing_path;
}
const char *tracing_path_mount(void)
--
2.14.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 08/11] perf cpu_map: Align cpu map synthesized events properly.
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
` (6 preceding siblings ...)
2018-10-17 22:54 ` [PATCH 07/11] perf tools: Fix tracing_path_mount proper path Arnaldo Carvalho de Melo
@ 2018-10-17 22:54 ` Arnaldo Carvalho de Melo
2018-10-17 22:54 ` [PATCH 09/11] perf report: Don't crash on invalid inline debug information Arnaldo Carvalho de Melo
` (3 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Arnaldo Carvalho de Melo @ 2018-10-17 22:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users, David Miller,
Jiri Olsa, Kan Liang, Arnaldo Carvalho de Melo
From: David Miller <davem@davemloft.net>
The size of the resulting cpu map can be smaller than a multiple of
sizeof(u64), resulting in SIGBUS on cpus like Sparc as the next event
will not be aligned properly.
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@intel.com>
Fixes: 6c872901af07 ("perf cpu_map: Add cpu_map event synthesize function")
Link: http://lkml.kernel.org/r/20181011.224655.716771175766946817.davem@davemloft.net
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/event.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 0cd42150f712..0988eb3b844b 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1081,6 +1081,7 @@ void *cpu_map_data__alloc(struct cpu_map *map, size_t *size, u16 *type, int *max
}
*size += sizeof(struct cpu_map_data);
+ *size = PERF_ALIGN(*size, sizeof(u64));
return zalloc(*size);
}
--
2.14.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 09/11] perf report: Don't crash on invalid inline debug information
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
` (7 preceding siblings ...)
2018-10-17 22:54 ` [PATCH 08/11] perf cpu_map: Align cpu map synthesized events properly Arnaldo Carvalho de Melo
@ 2018-10-17 22:54 ` Arnaldo Carvalho de Melo
2018-10-17 22:55 ` [PATCH 10/11] perf tools: Pass build flags to traceevent build Arnaldo Carvalho de Melo
` (2 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Arnaldo Carvalho de Melo @ 2018-10-17 22:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users, Milian Wolff,
Jin Yao, Jiri Olsa, Namhyung Kim, Arnaldo Carvalho de Melo
From: Milian Wolff <milian.wolff@kdab.com>
When the function name for an inline frame is invalid, we must not try
to demangle this symbol, otherwise we crash with:
#0 0x0000555555895c01 in bfd_demangle ()
#1 0x0000555555823262 in demangle_sym (dso=0x555555d92b90, elf_name=0x0, kmodule=0) at util/symbol-elf.c:215
#2 dso__demangle_sym (dso=dso@entry=0x555555d92b90, kmodule=<optimized out>, kmodule@entry=0, elf_name=elf_name@entry=0x0) at util/symbol-elf.c:400
#3 0x00005555557fef4b in new_inline_sym (funcname=0x0, base_sym=0x555555d92b90, dso=0x555555d92b90) at util/srcline.c:89
#4 inline_list__append_dso_a2l (dso=dso@entry=0x555555c7bb00, node=node@entry=0x555555e31810, sym=sym@entry=0x555555d92b90) at util/srcline.c:264
#5 0x00005555557ff27f in addr2line (dso_name=dso_name@entry=0x555555d92430 "/home/milian/.debug/.build-id/f7/186d14bb94f3c6161c010926da66033d24fce5/elf", addr=addr@entry=2888, file=file@entry=0x0,
line=line@entry=0x0, dso=dso@entry=0x555555c7bb00, unwind_inlines=unwind_inlines@entry=true, node=0x555555e31810, sym=0x555555d92b90) at util/srcline.c:313
#6 0x00005555557ffe7c in addr2inlines (sym=0x555555d92b90, dso=0x555555c7bb00, addr=2888, dso_name=0x555555d92430 "/home/milian/.debug/.build-id/f7/186d14bb94f3c6161c010926da66033d24fce5/elf")
at util/srcline.c:358
So instead handle the case where we get invalid function names for
inlined frames and use a fallback '??' function name instead.
While this crash was originally reported by Hadrien for rust code, I can
now also reproduce it with trivial C++ code. Indeed, it seems like
libbfd fails to interpret the debug information for the inline frame
symbol name:
$ addr2line -e /home/milian/.debug/.build-id/f7/186d14bb94f3c6161c010926da66033d24fce5/elf -if b48
main
/usr/include/c++/8.2.1/complex:610
??
/usr/include/c++/8.2.1/complex:618
??
/usr/include/c++/8.2.1/complex:675
??
/usr/include/c++/8.2.1/complex:685
main
/home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-inlining/main.cpp:39
I've reported this bug upstream and also attached a patch there which
should fix this issue:
https://sourceware.org/bugzilla/show_bug.cgi?id=23715
Reported-by: Hadrien Grasland <grasland@lal.in2p3.fr>
Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
Cc: Jin Yao <yao.jin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Fixes: a64489c56c30 ("perf report: Find the inline stack for a given address")
[ The above 'Fixes:' cset is where originally the problem was
introduced, i.e. using a2l->funcname without checking if it is NULL,
but this current patch fixes the current codebase, i.e. multiple csets
were applied after a64489c56c30 before the problem was reported by Hadrien ]
Link: http://lkml.kernel.org/r/20180926135207.30263-3-milian.wolff@kdab.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/srcline.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 09d6746e6ec8..e767c4a9d4d2 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -85,6 +85,9 @@ static struct symbol *new_inline_sym(struct dso *dso,
struct symbol *inline_sym;
char *demangled = NULL;
+ if (!funcname)
+ funcname = "??";
+
if (dso) {
demangled = dso__demangle_sym(dso, 0, funcname);
if (demangled)
--
2.14.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 10/11] perf tools: Pass build flags to traceevent build
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
` (8 preceding siblings ...)
2018-10-17 22:54 ` [PATCH 09/11] perf report: Don't crash on invalid inline debug information Arnaldo Carvalho de Melo
@ 2018-10-17 22:55 ` Arnaldo Carvalho de Melo
2018-10-17 22:55 ` [PATCH 11/11] perf tools: Stop fallbacking to kallsyms for vdso symbols lookup Arnaldo Carvalho de Melo
2018-10-18 5:44 ` [GIT PULL 00/11] perf/urgent fixes Ingo Molnar
11 siblings, 0 replies; 18+ messages in thread
From: Arnaldo Carvalho de Melo @ 2018-10-17 22:55 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users, Jiri Olsa,
Herton R. Krzesinski, Steven Rostedt, Tzvetomir Stoyanov,
Yordan Karadzhov, Arnaldo Carvalho de Melo
From: Jiri Olsa <jolsa@kernel.org>
So the extra user build flags are propagated to libtraceevent.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: "Herton R. Krzesinski" <herton@redhat.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
Cc: Yordan Karadzhov (VMware) <y.karadz@gmail.com>
Link: http://lkml.kernel.org/r/20181016150614.21260-3-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/Makefile.perf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 5224ade3d5af..0be411695379 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -635,7 +635,7 @@ $(LIBPERF_IN): prepare FORCE
$(LIB_FILE): $(LIBPERF_IN)
$(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(LIBPERF_IN) $(LIB_OBJS)
-LIBTRACEEVENT_FLAGS += plugin_dir=$(plugindir_SQ)
+LIBTRACEEVENT_FLAGS += plugin_dir=$(plugindir_SQ) 'EXTRA_CFLAGS=$(EXTRA_CFLAGS)' 'LDFLAGS=$(LDFLAGS)'
$(LIBTRACEEVENT): FORCE
$(Q)$(MAKE) -C $(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS) O=$(OUTPUT) $(OUTPUT)libtraceevent.a
--
2.14.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* [PATCH 11/11] perf tools: Stop fallbacking to kallsyms for vdso symbols lookup
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
` (9 preceding siblings ...)
2018-10-17 22:55 ` [PATCH 10/11] perf tools: Pass build flags to traceevent build Arnaldo Carvalho de Melo
@ 2018-10-17 22:55 ` Arnaldo Carvalho de Melo
2018-10-18 6:20 ` Adrian Hunter
2018-10-18 5:44 ` [GIT PULL 00/11] perf/urgent fixes Ingo Molnar
11 siblings, 1 reply; 18+ messages in thread
From: Arnaldo Carvalho de Melo @ 2018-10-17 22:55 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users,
Arnaldo Carvalho de Melo, Adrian Hunter, David Ahern, Jiri Olsa,
Namhyung Kim, Wang Nan
From: Arnaldo Carvalho de Melo <acme@redhat.com>
David reports that:
<quote>
Perf has this hack where it uses the kernel symbol map as a backup when
a symbol can't be found in the user's symbol table(s).
This causes problems because the tests driving this code path use
machine__kernel_ip(), and that is completely meaningless on Sparc. On
sparc64 the kernel and user live in physically separate virtual address
spaces, rather than a shared one. And the kernel lives at a virtual
address that overlaps common userspace addresses. So this test passes
almost all the time when a user symbol lookup fails.
The consequence of this is that, if the unfound user virtual address in
the sample doesn't match up to a kernel symbol either, we trigger things
like this code in builtin-top.c:
if (al.sym == NULL && al.map != NULL) {
const char *msg = "Kernel samples will not be resolved.\n";
/*
* As we do lazy loading of symtabs we only will know if the
* specified vmlinux file is invalid when we actually have a
* hit in kernel space and then try to load it. So if we get
* here and there are _no_ symbols in the DSO backing the
* kernel map, bail out.
*
* We may never get here, for instance, if we use -K/
* --hide-kernel-symbols, even if the user specifies an
* invalid --vmlinux ;-)
*/
if (!machine->kptr_restrict_warned && !top->vmlinux_warned &&
__map__is_kernel(al.map) && map__has_symbols(al.map)) {
if (symbol_conf.vmlinux_name) {
char serr[256];
dso__strerror_load(al.map->dso, serr, sizeof(serr));
ui__warning("The %s file can't be used: %s\n%s",
symbol_conf.vmlinux_name, serr, msg);
} else {
ui__warning("A vmlinux file was not found.\n%s",
msg);
}
if (use_browser <= 0)
sleep(5);
top->vmlinux_warned = true;
}
}
When I fire up a compilation on sparc, this triggers immediately.
I'm trying to figure out what the "backup to kernel map" code is
accomplishing.
I see some language in the current code and in the changes that have
happened in this area talking about vdso. Does that really happen?
The vdso is mapped into userspace virtual addresses, not kernel ones.
More history. This didn't cause problems on sparc some time ago,
because the kernel IP check used to be "ip < 0" :-) Sparc kernel
addresses are not negative. But now with machine__kernel_ip(), which
works using the symbol table determined kernel address range, it does
trigger.
What it all boils down to is that on architectures like sparc,
machine__kernel_ip() should always return false in this scenerio, and
therefore this kind of logic:
if (cpumode == PERF_RECORD_MISC_USER && machine &&
mg != &machine->kmaps &&
machine__kernel_ip(machine, al->addr)) {
is basically invalid. PERF_RECORD_MISC_USER implies no kernel address
can possibly match for the sample/event in question (no matter how
hard you try!) :-)
</>
So, I thought something had changed and in the past we would somehow
find that address in the kallsyms, but I couldn't find anything to back
that up, the patch introducing this is over a decade old, lots of things
changed, so I was just thinking I was missing something.
I tried a gtod busy loop to generate vdso activity and added a 'perf
probe' at that branch, on x86_64 to see if it ever gets hit:
Made thread__find_map() noinline, as 'perf probe' in lines of inline
functions seems to not be working, only at function start. (Masami?)
# perf probe -x ~/bin/perf -L thread__find_map:57
<thread__find_map@/home/acme/git/perf/tools/perf/util/event.c:57>
57 if (cpumode == PERF_RECORD_MISC_USER && machine &&
58 mg != &machine->kmaps &&
59 machine__kernel_ip(machine, al->addr)) {
60 mg = &machine->kmaps;
61 load_map = true;
62 goto try_again;
}
} else {
/*
* Kernel maps might be changed when loading
* symbols so loading
* must be done prior to using kernel maps.
*/
69 if (load_map)
70 map__load(al->map);
71 al->addr = al->map->map_ip(al->map, al->addr);
# perf probe -x ~/bin/perf thread__find_map:60
Added new event:
probe_perf:thread__find_map (on thread__find_map:60 in /home/acme/bin/perf)
You can now use it in all perf tools, such as:
perf record -e probe_perf:thread__find_map -aR sleep 1
#
Then used this to see if, system wide, those probe points were being hit:
# perf trace -e *perf:thread*/max-stack=8/
^C[root@jouet ~]#
No hits when running 'perf top' and:
# cat gtod.c
#include <sys/time.h>
int main(void)
{
struct timeval tv;
while (1)
gettimeofday(&tv, 0);
return 0;
}
[root@jouet c]# ./gtod
^C
Pressed 'P' in 'perf top' and the [vdso] samples are there:
62.84% [vdso] [.] __vdso_gettimeofday
8.13% gtod [.] main
7.51% [vdso] [.] 0x0000000000000914
5.78% [vdso] [.] 0x0000000000000917
5.43% gtod [.] _init
2.71% [vdso] [.] 0x000000000000092d
0.35% [kernel] [k] native_io_delay
0.33% libc-2.26.so [.] __memmove_avx_unaligned_erms
0.20% [vdso] [.] 0x000000000000091d
0.17% [i2c_i801] [k] i801_access
0.06% firefox [.] free
0.06% libglib-2.0.so.0.5400.3 [.] g_source_iter_next
0.05% [vdso] [.] 0x0000000000000919
0.05% libpthread-2.26.so [.] __pthread_mutex_lock
0.05% libpixman-1.so.0.34.0 [.] 0x000000000006d3a7
0.04% [kernel] [k] entry_SYSCALL_64_trampoline
0.04% libxul.so [.] style::dom_apis::query_selector_slow
0.04% [kernel] [k] module_get_kallsym
0.04% firefox [.] malloc
0.04% [vdso] [.] 0x0000000000000910
I added a 'perf probe' to thread__find_map:69, and that surely got tons
of hits, i.e. for every map found, just to make sure the 'perf probe'
command was really working.
In the process I noticed a bug, we're only have records for '[vdso]' for
pre-existing commands, i.e. ones that are running when we start 'perf top',
when we will generate the PERF_RECORD_MMAP by looking at /perf/PID/maps.
I.e. like this, for preexisting processes with a vdso map, again,
tracing for all the system, only pre-existing processes get a [vdso] map
(when having one):
[root@jouet ~]# perf probe -x ~/bin/perf __machine__addnew_vdso
Added new event:
probe_perf:__machine__addnew_vdso (on __machine__addnew_vdso in /home/acme/bin/perf)
You can now use it in all perf tools, such as:
perf record -e probe_perf:__machine__addnew_vdso -aR sleep 1
[root@jouet ~]# perf trace -e probe_perf:__machine__addnew_vdso/max-stack=8/
0.000 probe_perf:__machine__addnew_vdso:(568eb3)
__machine__addnew_vdso (/home/acme/bin/perf)
map__new (/home/acme/bin/perf)
machine__process_mmap2_event (/home/acme/bin/perf)
machine__process_event (/home/acme/bin/perf)
perf_event__process (/home/acme/bin/perf)
perf_tool__process_synth_event (/home/acme/bin/perf)
perf_event__synthesize_mmap_events (/home/acme/bin/perf)
__event__synthesize_thread (/home/acme/bin/perf)
The kernel is generating a PERF_RECORD_MMAP for vDSOs, but somehow
'perf top' is not getting those records while 'perf record' is:
# perf record ~acme/c/gtod
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.076 MB perf.data (1499 samples) ]
# perf report -D | grep PERF_RECORD_MMAP2
71293612401913 0x11b48 [0x70]: PERF_RECORD_MMAP2 25484/25484: [0x400000(0x1000) @ 0 fd:02 1137 541179306]: r-xp /home/acme/c/gtod
71293612419012 0x11be0 [0x70]: PERF_RECORD_MMAP2 25484/25484: [0x7fa4a2783000(0x227000) @ 0 fd:00 3146370 854107250]: r-xp /usr/lib64/ld-2.26.so
71293612432110 0x11c50 [0x60]: PERF_RECORD_MMAP2 25484/25484: [0x7ffcdb53a000(0x2000) @ 0 00:00 0 0]: r-xp [vdso]
71293612509944 0x11cb0 [0x70]: PERF_RECORD_MMAP2 25484/25484: [0x7fa4a23cd000(0x3b6000) @ 0 fd:00 3149723 262067164]: r-xp /usr/lib64/libc-2.26.so
#
# perf script | grep vdso | head
gtod 25484 71293.612768: 2485554 cycles:ppp: 7ffcdb53a914 [unknown] ([vdso])
gtod 25484 71293.613576: 2149343 cycles:ppp: 7ffcdb53a917 [unknown] ([vdso])
gtod 25484 71293.614274: 1814652 cycles:ppp: 7ffcdb53aca8 __vdso_gettimeofday+0x98 ([vdso])
gtod 25484 71293.614862: 1669070 cycles:ppp: 7ffcdb53acc5 __vdso_gettimeofday+0xb5 ([vdso])
gtod 25484 71293.615404: 1451589 cycles:ppp: 7ffcdb53acc5 __vdso_gettimeofday+0xb5 ([vdso])
gtod 25484 71293.615999: 1269941 cycles:ppp: 7ffcdb53ace6 __vdso_gettimeofday+0xd6 ([vdso])
gtod 25484 71293.616405: 1177946 cycles:ppp: 7ffcdb53a914 [unknown] ([vdso])
gtod 25484 71293.616775: 1121290 cycles:ppp: 7ffcdb53ac47 __vdso_gettimeofday+0x37 ([vdso])
gtod 25484 71293.617150: 1037721 cycles:ppp: 7ffcdb53ace6 __vdso_gettimeofday+0xd6 ([vdso])
gtod 25484 71293.617478: 994526 cycles:ppp: 7ffcdb53ace6 __vdso_gettimeofday+0xd6 ([vdso])
#
The patch is the obvious one and with it we also continue to resolve
vdso symbols for pre-existing processes in 'perf top' and for all
processes in 'perf record' + 'perf report/script'.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: https://lkml.kernel.org/n/tip-cs7skq9pp0kjypiju6o7trse@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/event.c | 21 ++-------------------
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 0988eb3b844b..bc646185f8d9 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1561,26 +1561,9 @@ struct map *thread__find_map(struct thread *thread, u8 cpumode, u64 addr,
return NULL;
}
-try_again:
+
al->map = map_groups__find(mg, al->addr);
- if (al->map == NULL) {
- /*
- * If this is outside of all known maps, and is a negative
- * address, try to look it up in the kernel dso, as it might be
- * a vsyscall or vdso (which executes in user-mode).
- *
- * XXX This is nasty, we should have a symbol list in the
- * "[vdso]" dso, but for now lets use the old trick of looking
- * in the whole kernel symbol list.
- */
- if (cpumode == PERF_RECORD_MISC_USER && machine &&
- mg != &machine->kmaps &&
- machine__kernel_ip(machine, al->addr)) {
- mg = &machine->kmaps;
- load_map = true;
- goto try_again;
- }
- } else {
+ if (al->map != NULL) {
/*
* Kernel maps might be changed when loading symbols so loading
* must be done prior to using kernel maps.
--
2.14.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [PATCH 11/11] perf tools: Stop fallbacking to kallsyms for vdso symbols lookup
2018-10-17 22:55 ` [PATCH 11/11] perf tools: Stop fallbacking to kallsyms for vdso symbols lookup Arnaldo Carvalho de Melo
@ 2018-10-18 6:20 ` Adrian Hunter
2018-10-26 23:19 ` Vinicius Costa Gomes
0 siblings, 1 reply; 18+ messages in thread
From: Adrian Hunter @ 2018-10-18 6:20 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users,
Arnaldo Carvalho de Melo, David Ahern, Jiri Olsa, Namhyung Kim,
Wang Nan
On 18/10/18 1:55 AM, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> David reports that:
>
> <quote>
> Perf has this hack where it uses the kernel symbol map as a backup when
> a symbol can't be found in the user's symbol table(s).
I don't think this is a complete fix because it exposes new problems. This
code caters for branches from kernel space to user space and vice versa.
That is, since there is only one cpumode so it is certain to be wrong for
either 'ip' or 'addr' when they are not both in the kernel or both in userspace.
>
>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: David Ahern <dsahern@gmail.com>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Wang Nan <wangnan0@huawei.com>
> Link: https://lkml.kernel.org/n/tip-cs7skq9pp0kjypiju6o7trse@git.kernel.org
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> ---
> tools/perf/util/event.c | 21 ++-------------------
> 1 file changed, 2 insertions(+), 19 deletions(-)
>
> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> index 0988eb3b844b..bc646185f8d9 100644
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c
> @@ -1561,26 +1561,9 @@ struct map *thread__find_map(struct thread *thread, u8 cpumode, u64 addr,
>
> return NULL;
> }
> -try_again:
> +
> al->map = map_groups__find(mg, al->addr);
> - if (al->map == NULL) {
> - /*
> - * If this is outside of all known maps, and is a negative
> - * address, try to look it up in the kernel dso, as it might be
> - * a vsyscall or vdso (which executes in user-mode).
> - *
> - * XXX This is nasty, we should have a symbol list in the
> - * "[vdso]" dso, but for now lets use the old trick of looking
> - * in the whole kernel symbol list.
> - */
> - if (cpumode == PERF_RECORD_MISC_USER && machine &&
> - mg != &machine->kmaps &&
> - machine__kernel_ip(machine, al->addr)) {
> - mg = &machine->kmaps;
> - load_map = true;
> - goto try_again;
> - }
> - } else {
> + if (al->map != NULL) {
> /*
> * Kernel maps might be changed when loading symbols so loading
> * must be done prior to using kernel maps.
>
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 11/11] perf tools: Stop fallbacking to kallsyms for vdso symbols lookup
2018-10-18 6:20 ` Adrian Hunter
@ 2018-10-26 23:19 ` Vinicius Costa Gomes
2018-10-27 11:05 ` Jiri Olsa
0 siblings, 1 reply; 18+ messages in thread
From: Vinicius Costa Gomes @ 2018-10-26 23:19 UTC (permalink / raw)
To: Adrian Hunter, Arnaldo Carvalho de Melo, Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users,
Arnaldo Carvalho de Melo, David Ahern, Jiri Olsa, Namhyung Kim,
Wang Nan
Hi,
Adrian Hunter <adrian.hunter@intel.com> writes:
> On 18/10/18 1:55 AM, Arnaldo Carvalho de Melo wrote:
>> From: Arnaldo Carvalho de Melo <acme@redhat.com>
>>
>> David reports that:
>>
>> <quote>
>> Perf has this hack where it uses the kernel symbol map as a backup when
>> a symbol can't be found in the user's symbol table(s).
>
> I don't think this is a complete fix because it exposes new problems.
This commit broke function name resolution for 'perf record -g' for me.
What I mean is, with this commit applied:
$ ./tools/perf/perf record -g -- sleep 1
$ ./tools/perf/perf report
'perf report' doesn't seem to be able to show the function names of the
trace.
If I revert this commit, function names are resolved fine.
> This code caters for branches from kernel space to user space and vice
> versa. That is, since there is only one cpumode so it is certain to be
> wrong for either 'ip' or 'addr' when they are not both in the kernel
> or both in userspace.
>
>>
>>
>> Cc: Adrian Hunter <adrian.hunter@intel.com>
>> Cc: David Ahern <dsahern@gmail.com>
>> Cc: Jiri Olsa <jolsa@kernel.org>
>> Cc: Namhyung Kim <namhyung@kernel.org>
>> Cc: Wang Nan <wangnan0@huawei.com>
>> Link: https://lkml.kernel.org/n/tip-cs7skq9pp0kjypiju6o7trse@git.kernel.org
>> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>> ---
>> tools/perf/util/event.c | 21 ++-------------------
>> 1 file changed, 2 insertions(+), 19 deletions(-)
>>
>> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
>> index 0988eb3b844b..bc646185f8d9 100644
>> --- a/tools/perf/util/event.c
>> +++ b/tools/perf/util/event.c
>> @@ -1561,26 +1561,9 @@ struct map *thread__find_map(struct thread *thread, u8 cpumode, u64 addr,
>>
>> return NULL;
>> }
>> -try_again:
>> +
>> al->map = map_groups__find(mg, al->addr);
>> - if (al->map == NULL) {
>> - /*
>> - * If this is outside of all known maps, and is a negative
>> - * address, try to look it up in the kernel dso, as it might be
>> - * a vsyscall or vdso (which executes in user-mode).
>> - *
>> - * XXX This is nasty, we should have a symbol list in the
>> - * "[vdso]" dso, but for now lets use the old trick of looking
>> - * in the whole kernel symbol list.
>> - */
>> - if (cpumode == PERF_RECORD_MISC_USER && machine &&
>> - mg != &machine->kmaps &&
>> - machine__kernel_ip(machine, al->addr)) {
>> - mg = &machine->kmaps;
>> - load_map = true;
>> - goto try_again;
>> - }
>> - } else {
>> + if (al->map != NULL) {
>> /*
>> * Kernel maps might be changed when loading symbols so loading
>> * must be done prior to using kernel maps.
>>
--
Vinicius
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 11/11] perf tools: Stop fallbacking to kallsyms for vdso symbols lookup
2018-10-26 23:19 ` Vinicius Costa Gomes
@ 2018-10-27 11:05 ` Jiri Olsa
2018-10-27 20:09 ` Vinicius Costa Gomes
0 siblings, 1 reply; 18+ messages in thread
From: Jiri Olsa @ 2018-10-27 11:05 UTC (permalink / raw)
To: Vinicius Costa Gomes
Cc: Adrian Hunter, Arnaldo Carvalho de Melo, Ingo Molnar,
Clark Williams, linux-kernel, linux-perf-users,
Arnaldo Carvalho de Melo, David Ahern, Jiri Olsa, Namhyung Kim,
Wang Nan
On Fri, Oct 26, 2018 at 04:19:52PM -0700, Vinicius Costa Gomes wrote:
> Hi,
>
> Adrian Hunter <adrian.hunter@intel.com> writes:
>
> > On 18/10/18 1:55 AM, Arnaldo Carvalho de Melo wrote:
> >> From: Arnaldo Carvalho de Melo <acme@redhat.com>
> >>
> >> David reports that:
> >>
> >> <quote>
> >> Perf has this hack where it uses the kernel symbol map as a backup when
> >> a symbol can't be found in the user's symbol table(s).
> >
> > I don't think this is a complete fix because it exposes new problems.
>
> This commit broke function name resolution for 'perf record -g' for me.
>
> What I mean is, with this commit applied:
>
> $ ./tools/perf/perf record -g -- sleep 1
>
> $ ./tools/perf/perf report
>
> 'perf report' doesn't seem to be able to show the function names of the
> trace.
>
> If I revert this commit, function names are resolved fine.
that commit just showed up some places where we have the
ip resolve wrong.. would attached patch fix it for you?
jirka
---
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 111ae858cbcb..72a5b803c797 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1824,7 +1824,7 @@ static void ip__resolve_ams(struct thread *thread,
* Thus, we have to try consecutively until we find a match
* or else, the symbol is unknown
*/
- thread__find_cpumode_addr_location(thread, ip, &al);
+ thread__find_cpumode_addr_location(thread, ip, &al, NULL);
ams->addr = ip;
ams->al_addr = al.addr;
@@ -1909,8 +1909,8 @@ static int add_callchain_ip(struct thread *thread,
al.filtered = 0;
al.sym = NULL;
- if (!cpumode) {
- thread__find_cpumode_addr_location(thread, ip, &al);
+ if (!cpumode || *cpumode == PERF_RECORD_MISC_CPUMODE_UNKNOWN) {
+ thread__find_cpumode_addr_location(thread, ip, &al, cpumode);
} else {
if (ip >= PERF_CONTEXT_MAX) {
switch (ip) {
@@ -2151,7 +2151,7 @@ static int thread__resolve_callchain_sample(struct thread *thread,
struct branch_stack *branch = sample->branch_stack;
struct ip_callchain *chain = sample->callchain;
int chain_nr = 0;
- u8 cpumode = PERF_RECORD_MISC_USER;
+ u8 cpumode = PERF_RECORD_MISC_CPUMODE_UNKNOWN;
int i, j, err, nr_entries;
int skip_idx = -1;
int first_call = 0;
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index 2048d393ece6..1cd83ecde501 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -366,7 +366,7 @@ int thread__fork(struct thread *thread, struct thread *parent, u64 timestamp)
}
void thread__find_cpumode_addr_location(struct thread *thread, u64 addr,
- struct addr_location *al)
+ struct addr_location *al, u8 *cpumode)
{
size_t i;
const u8 cpumodes[] = {
@@ -378,8 +378,11 @@ void thread__find_cpumode_addr_location(struct thread *thread, u64 addr,
for (i = 0; i < ARRAY_SIZE(cpumodes); i++) {
thread__find_symbol(thread, cpumodes[i], addr, al);
- if (al->map)
+ if (al->map) {
+ if (cpumode)
+ *cpumode = cpumodes[i];
break;
+ }
}
}
diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h
index 07606aa6998d..9aad9a71c943 100644
--- a/tools/perf/util/thread.h
+++ b/tools/perf/util/thread.h
@@ -99,7 +99,7 @@ struct symbol *thread__find_symbol(struct thread *thread, u8 cpumode,
u64 addr, struct addr_location *al);
void thread__find_cpumode_addr_location(struct thread *thread, u64 addr,
- struct addr_location *al);
+ struct addr_location *al, u8 *cpumode);
static inline void *thread__priv(struct thread *thread)
{
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [PATCH 11/11] perf tools: Stop fallbacking to kallsyms for vdso symbols lookup
2018-10-27 11:05 ` Jiri Olsa
@ 2018-10-27 20:09 ` Vinicius Costa Gomes
2018-10-28 21:10 ` Jiri Olsa
0 siblings, 1 reply; 18+ messages in thread
From: Vinicius Costa Gomes @ 2018-10-27 20:09 UTC (permalink / raw)
To: Jiri Olsa
Cc: Adrian Hunter, Arnaldo Carvalho de Melo, Ingo Molnar,
Clark Williams, linux-kernel, linux-perf-users,
Arnaldo Carvalho de Melo, David Ahern, Jiri Olsa, Namhyung Kim,
Wang Nan
Hi Jirka,
Jiri Olsa <jolsa@redhat.com> writes:
> On Fri, Oct 26, 2018 at 04:19:52PM -0700, Vinicius Costa Gomes wrote:
>> Hi,
>>
>> Adrian Hunter <adrian.hunter@intel.com> writes:
>>
>> > On 18/10/18 1:55 AM, Arnaldo Carvalho de Melo wrote:
>> >> From: Arnaldo Carvalho de Melo <acme@redhat.com>
>> >>
>> >> David reports that:
>> >>
>> >> <quote>
>> >> Perf has this hack where it uses the kernel symbol map as a backup when
>> >> a symbol can't be found in the user's symbol table(s).
>> >
>> > I don't think this is a complete fix because it exposes new problems.
>>
>> This commit broke function name resolution for 'perf record -g' for me.
>>
>> What I mean is, with this commit applied:
>>
>> $ ./tools/perf/perf record -g -- sleep 1
>>
>> $ ./tools/perf/perf report
>>
>> 'perf report' doesn't seem to be able to show the function names of the
>> trace.
>>
>> If I revert this commit, function names are resolved fine.
>
> that commit just showed up some places where we have the
> ip resolve wrong.. would attached patch fix it for you?
Thank you for your patch.
I can some difference in the output, but I wouldn't say that it's fixed.
Here are some samples, if it's useful somehow:
https://gist.github.com/vcgomes/985626705e0968b973e426964f86a4b0
The "ping" tests were done running
$ sudo ./tools/perf/perf record -g -- ping -f -c 1000 127.0.0.1
And the "sleep" tests were done running
$ sudo ./tools/perf/perf record -g -- /bin/sleep 1
--
Vinicius
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 11/11] perf tools: Stop fallbacking to kallsyms for vdso symbols lookup
2018-10-27 20:09 ` Vinicius Costa Gomes
@ 2018-10-28 21:10 ` Jiri Olsa
0 siblings, 0 replies; 18+ messages in thread
From: Jiri Olsa @ 2018-10-28 21:10 UTC (permalink / raw)
To: Vinicius Costa Gomes
Cc: Adrian Hunter, Arnaldo Carvalho de Melo, Ingo Molnar,
Clark Williams, linux-kernel, linux-perf-users,
Arnaldo Carvalho de Melo, David Ahern, Jiri Olsa, Namhyung Kim,
Wang Nan
On Sat, Oct 27, 2018 at 01:09:44PM -0700, Vinicius Costa Gomes wrote:
> Hi Jirka,
>
> Jiri Olsa <jolsa@redhat.com> writes:
>
> > On Fri, Oct 26, 2018 at 04:19:52PM -0700, Vinicius Costa Gomes wrote:
> >> Hi,
> >>
> >> Adrian Hunter <adrian.hunter@intel.com> writes:
> >>
> >> > On 18/10/18 1:55 AM, Arnaldo Carvalho de Melo wrote:
> >> >> From: Arnaldo Carvalho de Melo <acme@redhat.com>
> >> >>
> >> >> David reports that:
> >> >>
> >> >> <quote>
> >> >> Perf has this hack where it uses the kernel symbol map as a backup when
> >> >> a symbol can't be found in the user's symbol table(s).
> >> >
> >> > I don't think this is a complete fix because it exposes new problems.
> >>
> >> This commit broke function name resolution for 'perf record -g' for me.
> >>
> >> What I mean is, with this commit applied:
> >>
> >> $ ./tools/perf/perf record -g -- sleep 1
> >>
> >> $ ./tools/perf/perf report
> >>
> >> 'perf report' doesn't seem to be able to show the function names of the
> >> trace.
> >>
> >> If I revert this commit, function names are resolved fine.
> >
> > that commit just showed up some places where we have the
> > ip resolve wrong.. would attached patch fix it for you?
>
> Thank you for your patch.
>
> I can some difference in the output, but I wouldn't say that it's fixed.
>
> Here are some samples, if it's useful somehow:
>
> https://gist.github.com/vcgomes/985626705e0968b973e426964f86a4b0
>
> The "ping" tests were done running
>
> $ sudo ./tools/perf/perf record -g -- ping -f -c 1000 127.0.0.1
>
> And the "sleep" tests were done running
>
> $ sudo ./tools/perf/perf record -g -- /bin/sleep 1
ugh, I tried with 'sudo ./perf record -g' and it looks
like it matter to callchains if there's a workload
Adrian said he's preparing complex patch for this
let's wait for his changes
thanks,
jirka
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 00/11] perf/urgent fixes
2018-10-17 22:54 [GIT PULL 00/11] perf/urgent fixes Arnaldo Carvalho de Melo
` (10 preceding siblings ...)
2018-10-17 22:55 ` [PATCH 11/11] perf tools: Stop fallbacking to kallsyms for vdso symbols lookup Arnaldo Carvalho de Melo
@ 2018-10-18 5:44 ` Ingo Molnar
11 siblings, 0 replies; 18+ messages in thread
From: Ingo Molnar @ 2018-10-18 5:44 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Clark Williams, linux-kernel, linux-perf-users, Adrian Hunter,
Alexander Shishkin, Andi Kleen, David Ahern, David S . Miller,
Drew Schmitt, Hadrien Grasland, Herton R. Krzesinski,
Jarod Wilson, Jin Yao, Jiri Olsa, John Garry, Kan Liang,
linuxarm, linux-arm-kernel, Mark Rutland, Michael Petlan,
Milian Wolff, Namhyung Kim, Paolo Bonzini, Peter Zijlstra,
Stephane Eranian, Steven Rostedt, Tzvetomir Stoyanov,
Vitaly Kuznetsov, Wang Nan, Will Deacon, William Cohen,
Yordan Karadzhov, Arnaldo Carvalho de Melo
* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> Best Regards,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit c1883f10cfe05c707cce46d6999411c50a2413ca:
>
> Merge tag 'perf-urgent-for-mingo-4.19-20181005' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent (2018-10-05 18:14:00 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-4.19-20181017
>
> for you to fetch changes up to edeb0c90df3581b821a764052d185df985f8b8dc:
>
> perf tools: Stop fallbacking to kallsyms for vdso symbols lookup (2018-10-17 15:56:15 -0300)
>
> ----------------------------------------------------------------
> perf/urgent fixes:
>
> - Stop fallbacking to kallsyms for vDSO symbols lookup, this wasn't
> being really used and is not valid in arches such as Sparc, where
> user and kernel space don't share the address space, relying only on
> cpumode to figure out what DSOs to lookup (Arnaldo Carvalho de Melo)
>
> - Align cpu map synthesized events properly, fixing SIGBUS in
> CPUs like Sparc (David Miller)
>
> - Fix use of alternatives to find JDIR (Jarod Wilson)
>
> - Store ids for events with their own cpus when synthesizing user
> level event details (scale, unit, etc) events, fixing a crash
> when recording a PMU event with a cpumask defined (Jiri Olsa)
>
> - Fix wrong filter_band* values for uncore Intel vendor events (Jiri Olsa)
>
> - Fix detection of tracefs path in systems without tracefs, where
> that path should be the debugfs mountpoint plus "/tracing/" (Jiri Olsa)
>
> - Pass build flags to traceevent build, allowing using alternative
> flags in distro packages, RPM, for instance (Jiri Olsa)
>
> - Fix 'perf report' crash on invalid inline debug information (Milian Wolff)
>
> - Synch kvm uapi copies (Arnaldo Carvalho de Melo)
>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> ----------------------------------------------------------------
> Arnaldo Carvalho de Melo (3):
> tools arch uapi: Sync the x86 kvm.h copy
> tools headers uapi: Sync kvm.h copy
> perf tools: Stop fallbacking to kallsyms for vdso symbols lookup
>
> David Miller (1):
> perf cpu_map: Align cpu map synthesized events properly.
>
> Jarod Wilson (1):
> perf tools: Fix use of alternatives to find JDIR
>
> Jiri Olsa (5):
> Revert "perf tools: Fix PMU term format max value calculation"
> perf vendor events intel: Fix wrong filter_band* values for uncore events
> perf evsel: Store ids for events with their own cpus perf_event__synthesize_event_update_cpus
> perf tools: Fix tracing_path_mount proper path
> perf tools: Pass build flags to traceevent build
>
> Milian Wolff (1):
> perf report: Don't crash on invalid inline debug information
>
> tools/arch/x86/include/uapi/asm/kvm.h | 1 +
> tools/include/uapi/linux/kvm.h | 1 +
> tools/lib/api/fs/tracing_path.c | 4 ++--
> tools/perf/Makefile.config | 2 +-
> tools/perf/Makefile.perf | 2 +-
> tools/perf/builtin-report.c | 1 +
> .../pmu-events/arch/x86/ivytown/uncore-power.json | 16 ++++++++--------
> .../pmu-events/arch/x86/jaketown/uncore-power.json | 16 ++++++++--------
> tools/perf/util/event.c | 22 +++-------------------
> tools/perf/util/evsel.c | 3 +++
> tools/perf/util/pmu.c | 13 +++++++------
> tools/perf/util/srcline.c | 3 +++
> 12 files changed, 39 insertions(+), 45 deletions(-)
Pulled, thanks a lot Arnaldo!
Ingo
^ permalink raw reply [flat|nested] 18+ messages in thread