perf: add memory access sampling support
Subsystems (2)
v2 cover perf: add memory access sampling support
This patch series had a new feature to the kernel perf_events interface and corresponding user level tool, perf.
With this patch, it is possible to sample (not trace) memory accesses (load, store). For loads, the instruction and data addresses are captured along with the latency and data source. For stores, the instruction and data addresses are capture along with limited cache and TLB information.
For load data source, the memory hierarchy level, the tlb, snoop and lock information is captured.
Although the perf_event interface is extended in a generic manner, sampling memory accesses requires HW support. The current patches implement the feature on Intel processors starting with Nehalem. The patches leverage the PEBS Load Latency and Precise Store mechanisms. Precise Store is present only on Sandy Bridge and Ivy Bridge based processors.
The perf tool is extended to make capturing and analyzing the data easier with a new command: perf mem.
$ perf mem -t load rec triad
$ perf mem -t load rep --stdio
# Samples: 19K of event 'cpu/mem-loads/pp'
# Total cost : 1013994
# Sort order : cost,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked
#
# Overhead Samples Cost Memory access Symbol Shared Obj Data Symbol Data Object Snoop TLB access Locked
# ........ ........... ....... ............. .......... ........... ...................... ........... ...... ............ ......
#
0.10% 1 986 LFB hit [.] triad triad [.] 0x00007f67dffe8038 [unknown] None L1 or L2 hit No
0.09% 1 890 LFB hit [.] triad triad [.] 0x00007f67df91a750 [unknown] None L1 or L2 hit No
0.08% 1 826 LFB hit [.] triad triad [.] 0x00007f67e288fba8 [unknown] None L1 or L2 hit No
0.08% 1 825 LFB hit [.] triad triad [.] 0x00007f67dea28c80 [unknown] None L1 or L2 hit No
0.08% 1 787 LFB hit [.] triad triad [.] 0x00007f67df055a60 [unknown] None L1 or L2 hit No The perf mem command is a wrapper around perf record/report. It passes the right options to the report and record commands. Note that the TUI mode is supported.
One powerful feature of perf is that users can toy with sort order to display the information in different format or from a different angle. This is particularly useful with memory sampling:
$ perf mem -t load rep --sort=mem
# Samples: 19K of event 'cpu/mem-loads/pp'
# Total cost : 1013994
# Sort order : mem
#
# Overhead Samples Memory access
# ........ ........... ........................
#
85.26% 10633 LFB hit
7.35% 8151 L1 hit
3.13% 383 L3 hit
3.09% 195 Local RAM hit
1.16% 259 L2 hit
0.00% 4 Uncached hit Or if one is interested in the data view:
$ perf mem -t load rep --sort=symbol_daddr,cost
# Samples: 19K of event 'cpu/mem-loads/pp'
# Total cost : 1013994
# Sort order : symbol_daddr,cost
#
# Overhead Samples Data Symbol Cost
# ........ ........... ...................... .......
#
0.10% 1 [.] 0x00007f67dffe8038 986
0.09% 1 [.] 0x00007f67df91a750 890
0.08% 1 [.] 0x00007f67e288fba8 826One note on the cost displayed: On Intel processors with PEBS Load Latency, as described in the SDM, the cost encompasses the number of cycles from dispatch to Globally Observable (GO) state. That means, that it includes OOO execution. It is not usual to see L1D Hits with a cost of > 100 cycles. Always look at the memory level for an approximation of the access penalty, then interpret the cost value accordingly.
There is no cost associated with stores.
CAVEAT: Note that the data addresses are not resolved correctly currently due to a problem in perf data symbol resolution code which I have not been able to uncover so far.
In v2, we leverage some of Andi Kleen's Haswell patches, namely the weighted samples and perf tool event parser fixes. We also introduce PERF_RECORD_MISC_DATA_MMAP to tag mmaps for data vs. code. This helps the perf tool distinguish data. vs. code mmaps (and therefore symbols). We have also integrated the feedback from v1. Note that in v2 data symbol resolution is not yet fully operational, but there is a slight improvement.
Enjoy,
Andi Kleen (2):
perf, core: Add a concept of a weightened sample perf, tools: Add arbitary aliases and support names with -
Stephane Eranian (14):
perf/x86: improve sysfs event mapping with event string perf/x86: add flags to event constraints
perf: add minimal support for PERF_SAMPLE_WEIGHT
perf: add support for PERF_SAMPLE_ADDR in dump_sampple()
perf: add generic memory sampling interface perf/x86: add memory profiling via PEBS Load Latency perf/x86: export PEBS load latency threshold register to sysfs perf/x86: add support for PEBS Precise Store
perf tools: add mem access sampling core support perf report: add support for mem access profiling perf record: add support for mem access profiling perf tools: add new mem command for memory access profiling
perf: add PERF_RECORD_MISC_MMAP_DATA to RECORD_MMAP perf tools: detect data vs. text mappings
arch/x86/include/asm/msr-index.h | 1 + arch/x86/kernel/cpu/perf_event.c | 33 +-- arch/x86/kernel/cpu/perf_event.h | 61 ++++- arch/x86/kernel/cpu/perf_event_intel.c | 66 ++++- arch/x86/kernel/cpu/perf_event_intel_ds.c | 182 +++++++++++++- arch/x86/kernel/cpu/perf_event_intel_uncore.c | 2 +- include/linux/perf_event.h | 5 + include/uapi/linux/perf_event.h | 74 +++++- kernel/events/core.c | 15 ++ tools/perf/Documentation/perf-mem.txt | 48 ++++ tools/perf/Makefile | 1 + tools/perf/builtin-mem.c | 238 ++++++++++++++++++ tools/perf/builtin-record.c | 2 + tools/perf/builtin-report.c | 131 +++++++++- tools/perf/builtin.h | 1 + tools/perf/command-list.txt | 1 + tools/perf/perf.c | 1 + tools/perf/perf.h | 1 + tools/perf/util/event.h | 2 + tools/perf/util/evsel.c | 15 ++ tools/perf/util/hist.c | 66 ++++- tools/perf/util/hist.h | 13 + tools/perf/util/machine.c | 10 +- tools/perf/util/parse-events.l | 2 + tools/perf/util/session.c | 44 ++++ tools/perf/util/session.h | 4 + tools/perf/util/sort.c | 324 ++++++++++++++++++++++++- tools/perf/util/sort.h | 10 +- tools/perf/util/symbol.h | 7 + 29 files changed, 1312 insertions(+), 48 deletions(-) create mode 100644 tools/perf/Documentation/perf-mem.txt create mode 100644 tools/perf/builtin-mem.c
Signature · 1 line
1.7.9.5
PATCH v2 1/16 perf/x86: improve sysfs event mapping with event string
This patch extends Jiri's changes to make generic events mapping visible via sysfs. The patch extends the mechanism to non-generic events by allowing the mappings to be hardcoded in strings.
This mechanism will be used by the PEBS-LL patch later on.
--- arch/x86/kernel/cpu/perf_event.c | 28 +++++++++++++--------------- arch/x86/kernel/cpu/perf_event.h | 26 ++++++++++++++++++++++++++ 2 files changed, 39 insertions(+), 15 deletions(-)
arch/x86/kernel/cpu/perf_event.c +13 -15
@@ -1316,20 +1316,22 @@ static struct attribute_group x86_pmu_format_group = { .attrs = NULL, }; -struct perf_pmu_events_attr { -struct device_attribute attr; -u64 id; -}; -/* * Remove all undefined events (x86_pmu.event_map(id) == 0) * out of events_attr attributes. */ static void __init filter_events (struct attribute **attrs) { +struct device_attribute *d; +struct perf_pmu_events_attr *pmu_attr;int i, j;for (i =0 ; attrs[i]; i++) { + d = (struct device_attribute *)attrs[i]; + pmu_attr = container_of(d, struct perf_pmu_events_attr, attr); +/* str trumps id */ +if (pmu_attr->event_str) +continue ;if (x86_pmu.event_map (i))continue ;
@@ -1341,24 +1343,20 @@ static void __init filter_events(struct attribute **attrs) } } -static ssize_t events_sysfs_show (struct device *dev,struct device_attribute *attr, +ssize_t events_sysfs_show (struct device *dev,struct device_attribute *attr,char *page) {struct perf_pmu_events_attr *pmu_attr = \ container_of(attr, struct perf_pmu_events_attr, attr);u64 config = x86_pmu.event_map (pmu_attr->id); -return x86_pmu.events_sysfs_show (page, config); -} -#define EVENT_VAR (_id) event_attr_##_id -#define EVENT_PTR (_id) &event_attr_##_id.attr.attr +/* string trumps id */ +if (pmu_attr->event_str) +return sprintf (page,"%s" , pmu_attr->event_str); -#define EVENT_ATTR (_name, _id) \ -static struct perf_pmu_events_attr EVENT_VAR(_id) = { \ - .attr = __ATTR(_name, 0444, events_sysfs_show, NULL), \ - .id = PERF_COUNT_HW_##_id, \ -}; +return x86_pmu.events_sysfs_show (page, config); +}EVENT_ATTR (cpu-cycles,CPU_CYCLES );EVENT_ATTR (instructions,INSTRUCTIONS );
arch/x86/kernel/cpu/perf_event.h +26 -0
@@ -419,6 +419,29 @@ do { \#define ERF_NO_HT_SHARING 1#define ERF_HAS_RSP_1 2 +#define EVENT_VAR (_id) event_attr_##_id +#define EVENT_PTR (_id) &event_attr_##_id.attr.attr + +#define EVENT_ATTR (_name, _id) \ +static struct perf_pmu_events_attr EVENT_VAR(_id) = { \ + .attr = __ATTR(_name, 0444, events_sysfs_show, NULL), \ + .id = PERF_COUNT_HW_##_id, \ + .event_str = NULL, \ +}; + +#define EVENT_ATTR_STR (_name, v, str) \ +static struct perf_pmu_events_attr event_attr_##v = { \ + .attr = __ATTR(_name, 0444, events_sysfs_show, NULL),\ + .id = 0, \ + .event_str = str, \ +}; + +struct perf_pmu_events_attr { +struct device_attribute attr; +u64 id; +const char *event_str; +}; +extern struct x86_pmu x86_pmu__read_mostly ; DECLARE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
@@ -633,6 +656,9 @@ int p6_pmu_init(void);int knc_pmu_init (void ); +ssize_t events_sysfs_show (struct device *dev,struct device_attribute *attr, +char *page); +#else /* CONFIG_CPU_SUP_INTEL */ static inline void reserve_ds_buffers (void )
Signature · 1 line
1.7.9.5
PATCH v2 2/16 perf/x86: add flags to event constraints
In reply to Stephane EranianThis patch adds a flags field to each event constraint. It can be used to store event specific features which can then later be used by scheduling code or low-level x86 code.
The flags are propagated into event->hw.flags during the get_event_constraint() call. They are cleared during the put_event_constraint() call.
This mechanism is going to be used by the PEBS-LL patches. It avoids defining yet another table to hold event specific information.
--- arch/x86/kernel/cpu/perf_event.c | 2 +- arch/x86/kernel/cpu/perf_event.h | 8 +++++--- arch/x86/kernel/cpu/perf_event_intel.c | 5 ++++- arch/x86/kernel/cpu/perf_event_intel_ds.c | 4 +++- arch/x86/kernel/cpu/perf_event_intel_uncore.c | 2 +- include/linux/perf_event.h | 1 + 6 files changed, 15 insertions(+), 7 deletions(-)
arch/x86/kernel/cpu/perf_event.c +1 -1
@@ -1470,7 +1470,7 @@ static int __init init_hw_perf_events(void) unconstrained = (struct event_constraint )__EVENT_CONSTRAINT (0 , (1ULL << x86_pmu.num_counters) -1 , -0 , x86_pmu.num_counters,0 ); +0 , x86_pmu.num_counters,0 ,0 ); x86_pmu.attr_rdpmc =1 ;/* enable userspace RDPMC usage by default */ x86_pmu_format_group.attrs = x86_pmu.format_attrs;
arch/x86/kernel/cpu/perf_event.h +5 -3
@@ -59,6 +59,7 @@ struct event_constraint {u64 cmask;int weight;int overlap; +int flags; };struct amd_nb {
@@ -170,16 +171,17 @@ struct cpu_hw_events {void *kfree_on_online; }; -#define __EVENT_CONSTRAINT (c, n, m, w, o) {\ +#define __EVENT_CONSTRAINT (c, n, m, w, o, f) {\ { .idxmsk64 = (n) }, \ .code = (c), \ .cmask = (m), \ .weight = (w), \ .overlap = (o), \ + .flags = f, \ }#define EVENT_CONSTRAINT (c, n, m) \ - __EVENT_CONSTRAINT(c, n, m, HWEIGHT(n), 0) + __EVENT_CONSTRAINT(c, n, m, HWEIGHT(n), 0, 0)/* * The overlap flag marks event constraints with overlapping counter
@@ -203,7 +205,7 @@ struct cpu_hw_events {* and its counter masks must be kept at a minimum. */ #define EVENT_CONSTRAINT_OVERLAP (c, n, m) \ - __EVENT_CONSTRAINT(c, n, m, HWEIGHT(n), 1) + __EVENT_CONSTRAINT(c, n, m, HWEIGHT(n), 1, 0)/* * Constraint on the Event code.
arch/x86/kernel/cpu/perf_event_intel.c +4 -1
@@ -1367,8 +1367,10 @@ x86_get_event_constraints(struct cpu_hw_events *cpuc, struct perf_event *event)if (x86_pmu.event_constraints) {for_each_event_constraint (c, x86_pmu.event_constraints) { -if ((event->hw.config & c->cmask) == c->code) +if ((event->hw.config & c->cmask) == c->code) { + event->hw.flags |= c->flags;return c; + } } }
@@ -1413,6 +1415,7 @@ intel_put_shared_regs_event_constraints(struct cpu_hw_events *cpuc,static void intel_put_event_constraints (struct cpu_hw_events *cpuc,struct perf_event *event) { + event->hw.flags =0 ;intel_put_shared_regs_event_constraints (cpuc, event); }
arch/x86/kernel/cpu/perf_event_intel_ds.c +3 -1
@@ -430,8 +430,10 @@ struct event_constraint *intel_pebs_constraints(struct perf_event *event)if (x86_pmu.pebs_constraints) {for_each_event_constraint (c, x86_pmu.pebs_constraints) { -if ((event->hw.config & c->cmask) == c->code) +if ((event->hw.config & c->cmask) == c->code) { + event->hw.flags |= c->flags;return c; + } } }
arch/x86/kernel/cpu/perf_event_intel_uncore.c +1 -1
@@ -2438,7 +2438,7 @@ static int __init uncore_type_init(struct intel_uncore_type *type) type->unconstrainted = (struct event_constraint )__EVENT_CONSTRAINT (0 , (1ULL << type->num_counters) -1 , -0 , type->num_counters,0 ); +0 , type->num_counters,0 ,0 );for (i =0 ; i < type->num_boxes; i++) { pmus[i].func_id =-1 ;
include/linux/perf_event.h +1 -0
@@ -128,6 +128,7 @@ struct hw_perf_event {int event_base_rdpmc;int idx;int last_cpu; +int flags;struct hw_perf_event_extra extra_reg;struct hw_perf_event_extra branch_reg;
Signature · 1 line
1.7.9.5
PATCH v2 3/16 perf, core: Add a concept of a weightened sample
In reply to Stephane EranianFrom: Andi Kleen <[email protected]>
For some events it's useful to weight sample with a hardware provided number. This expresses how expensive the action the sample represent was. This allows the profiler to scale the samples to be more informative to the programmer.
There is already the period which is used similarly, but it means something different, so I chose to not overload it. Instead a new sample type for WEIGHT is added.
Can be used for multiple things. Initially it is used for TSX abort costs and profiling by memory latencies (so to make expensive load appear higher up in the histograms) The concept is quite generic and can be extended to many other kinds of events or architectures, as long as the hardware provides suitable auxillary values. In principle it could be also used for software tracpoints.
This adds the generic glue. A new optional sample format for a 64bit weight value.
--- include/linux/perf_event.h | 2 ++ include/uapi/linux/perf_event.h | 8 ++++++-- kernel/events/core.c | 6 ++++++ 3 files changed, 14 insertions(+), 2 deletions(-)
include/linux/perf_event.h +2 -0
@@ -584,6 +584,7 @@ struct perf_sample_data {struct perf_branch_stack *br_stack;struct perf_regs_user regs_user;u64 stack_user_size; +u64 weight; }; static inline void perf_sample_data_init(struct perf_sample_data *data,
@@ -597,6 +598,7 @@ static inline void perf_sample_data_init(struct perf_sample_data *data, data->regs_user.abi =PERF_SAMPLE_REGS_ABI_NONE ; data->regs_user.regs =NULL ; data->stack_user_size =0 ; + data->weight =0 ; } extern void perf_output_sample(struct perf_output_handle *handle,
include/uapi/linux/perf_event.h +6 -2
@@ -132,8 +132,10 @@ enum perf_event_sample_format {PERF_SAMPLE_BRANCH_STACK =1U <<11 ,PERF_SAMPLE_REGS_USER =1U <<12 ,PERF_SAMPLE_STACK_USER =1U <<13 , +PERF_SAMPLE_WEIGHT =1U <<14 , + + PERF_SAMPLE_MAX = 1U << 15, /* non-ABI */ - PERF_SAMPLE_MAX = 1U << 14, /* non-ABI */ };/*
@@ -198,8 +200,9 @@ enum perf_event_read_format {PERF_FORMAT_TOTAL_TIME_RUNNING =1U <<1 ,PERF_FORMAT_ID =1U <<2 ,PERF_FORMAT_GROUP =1U <<3 , +PERF_FORMAT_WEIGHT =1U <<4 , - PERF_FORMAT_MAX = 1U << 4, /* non-ABI */ + PERF_FORMAT_MAX = 1U << 5, /* non-ABI */ };#define PERF_ATTR_SIZE_VER0 64/* sizeof first published struct */
@@ -559,6 +562,7 @@ enum perf_event_type {* { u64 stream_id;} && PERF_SAMPLE_STREAM_ID * { u32 cpu, res; } && PERF_SAMPLE_CPU * { u64 period; } && PERF_SAMPLE_PERIOD +* { u64 weight; } && PERF_SAMPLE_WEIGHT * * { struct read_format values; } && PERF_SAMPLE_READ *
kernel/events/core.c +6 -0
@@ -952,6 +952,9 @@ static void perf_event__header_size(struct perf_event *event)if (sample_type &PERF_SAMPLE_PERIOD ) size +=sizeof (data->period); +if (sample_type &PERF_SAMPLE_WEIGHT ) + size +=sizeof (data->weight); +if (sample_type &PERF_SAMPLE_READ ) size += event->read_size;
@@ -4080,6 +4083,9 @@ void perf_output_sample(struct perf_output_handle *handle,if (sample_type &PERF_SAMPLE_PERIOD )perf_output_put (handle, data->period); +if (sample_type &PERF_SAMPLE_WEIGHT ) +perf_output_put (handle, data->weight); +if (sample_type &PERF_SAMPLE_READ )perf_output_read (handle, event);
Signature · 1 line
1.7.9.5
Re: [PATCH v2 03/16] perf, core: Add a concept of a weightened sample
Em Mon, Nov 05, 2012 at 02:50:50PM +0100, Stephane Eranian escreveu:
include/uapi/linux/perf_event.h enum perf_event_type { · line 567
Quoted 10 lines
include/uapi/linux/perf_event.h +1
-0#define PERF_ATTR_SIZE_VER0 64/* sizeof first published struct */ @@ -559,6 +562,7 @@ enum perf_event_type {* { u64 stream_id;} && PERF_SAMPLE_STREAM_ID * { u32 cpu, res; } && PERF_SAMPLE_CPU * { u64 period; } && PERF_SAMPLE_PERIOD +* { u64 weight; } && PERF_SAMPLE_WEIGHT * * { struct read_format values; } && PERF_SAMPLE_READ
This comes after PERF_SAMPLE_STACK_USER so that perf_evsel__parse_sample can get it right, isn't it? Or is just the comment wrong?
kernel/events/core.c static void perf_event__header_size(struct perf_event *event) · line 956
Quoted 10 lines
kernel/events/core.c +2
-0@@ -952,6 +952,9 @@ static void perf_event__header_size(struct perf_event *event)if (sample_type &PERF_SAMPLE_PERIOD ) size +=sizeof (data->period); +if (sample_type &PERF_SAMPLE_WEIGHT ) + size +=sizeof (data->weight);
Here it doesn't matter, we're just computing the sample size, but would be nice to add this just after the (sample_type & PERF_SAMPLE_STACK_USER) branch.
kernel/events/core.c void perf_output_sample(struct perf_output_handle *handle, · line 4088
Quoted 11 lines
kernel/events/core.c +4
-0+if (sample_type &PERF_SAMPLE_READ ) size += event->read_size;@@ -4080,6 +4083,9 @@ void perf_output_sample(struct perf_output_handle *handle,if (sample_type &PERF_SAMPLE_PERIOD )perf_output_put (handle, data->period); +if (sample_type &PERF_SAMPLE_WEIGHT ) +perf_output_put (handle, data->weight); +
Yeap, it should go after PERF_SAMPLE_STACK_USER
Quoted 5 lines
kernel/events/core.c +0
-0if (sample_type &PERF_SAMPLE_READ )perf_output_read (handle, event);Signature · 1 line
1.7.9.5
Re: [PATCH v2 03/16] perf, core: Add a concept of a weightened sample
Em Mon, Nov 05, 2012 at 05:01:47PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 8 lines
Quoted 8 lines
(quoted diff) +1
-0+ if (sample_type & PERF_SAMPLE_READ) size += event->read_size;@@ -4080,6 +4083,9 @@ void perf_output_sample(struct perf_output_handle *handle, if (sample_type & PERF_SAMPLE_PERIOD) perf_output_put(handle, data->period);
Quoted 9 lines
Review void perf_output_sample(struct perf_output_handle *handle, · line 4088
Quoted 3 lines
(quoted diff) +3
-0+ if (sample_type & PERF_SAMPLE_WEIGHT) + perf_output_put(handle, data->weight); +Yeap, it should go after
PERF_SAMPLE_STACK_USERQuoted 3 lines
(quoted diff) +0
-0if (sample_type & PERF_SAMPLE_READ) perf_output_read(handle, event);
I mean this, on top of the above patch:
kernel/events/core.c +3 -3
@@ -4083,9 +4083,6 @@if (sample_type &PERF_SAMPLE_PERIOD )perf_output_put (handle, data->period); -if (sample_type &PERF_SAMPLE_WEIGHT ) -perf_output_put (handle, data->weight); -if (sample_type &PERF_SAMPLE_READ )perf_output_read (handle, event);
@@ -4175,6 +4172,9 @@perf_output_sample_ustack (handle, data->stack_user_size, data->regs_user.regs); + +if (sample_type &PERF_SAMPLE_WEIGHT ) +perf_output_put (handle, data->weight); } void perf_prepare_sample(struct perf_event_header *header,
------------
To match what this patch series will do on a later patch, i.e. parse the weight at the end of perf_evsel__parse_sample, after it parses PERF_SAMPLE_READ, PERF_SAMPLE_CALLCHAIN, PERF_SAMPLE_RAW, PERF_SAMPLE_BRANCH_STACK, PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER:
+++ b/tools/perf/util/evsel.c
@@ -1020,6 +1020,11 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel, union perf_event *event,
}
}+ if (type & PERF_SAMPLE_WEIGHT) {
+ data->weight= *array;
+ array++;
+ }
+
return 0;
}
- Arnaldo
Re: [PATCH v2 03/16] perf, core: Add a concept of a weightened sample
In reply to Arnaldo Carvalho de MeloQuoted 8 lines
Quoted 8 lines
kernel/events/core.c +1
-0+if (sample_type &PERF_SAMPLE_READ ) size += event->read_size;@@ -4080,6 +4083,9 @@ void perf_output_sample(struct perf_output_handle *handle,if (sample_type &PERF_SAMPLE_PERIOD )perf_output_put (handle, data->period);
Quoted 5 lines
kernel/events/core.c void perf_output_sample(struct perf_output_handle *handle, · line 4088
Quoted 3 lines
kernel/events/core.c +3
-0+if (sample_type &PERF_SAMPLE_WEIGHT ) +perf_output_put (handle, data->weight); +Yeap, it should go after
PERF_SAMPLE_STACK_USER
There was a bug I recently noticed but haven't investigated so far.
When I do -b -W --transaction the flags/weights get corrupted.
May be related to that.
-Andi
Signature · 1 line
[email protected] -- Speaking for myself only
PATCH v2 4/16 perf: add minimal support for PERF_SAMPLE_WEIGHT
In reply to Stephane EranianEnsure we grab the weight from raw sample struct
and that we can dump it via perf report -D.
--- tools/perf/util/event.h | 1 + tools/perf/util/evsel.c | 5 +++++ tools/perf/util/session.c | 3 +++ 3 files changed, 9 insertions(+)
tools/perf/util/event.h +1 -0
@@ -90,6 +90,7 @@ struct perf_sample {u64 period;u32 cpu;u32 raw_size; +u64 weight;void *raw_data;struct ip_callchain *callchain;struct branch_stack *branch_stack;
tools/perf/util/evsel.c +5 -0
@@ -1020,6 +1020,11 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel, union perf_event *event, } } +if (type &PERF_SAMPLE_WEIGHT ) { + data->weight= *array; + array++; + } +return 0 ; }
tools/perf/util/session.c +3 -0
@@ -1006,6 +1006,9 @@ static void dump_sample(struct perf_evsel *evsel, union perf_event *event,if (sample_type &PERF_SAMPLE_STACK_USER )stack_user__printf (&sample->user_stack); + +if (sample_type &PERF_SAMPLE_WEIGHT ) +printf (" ... weight: %" PRIu64"\n" , sample->weight); } static struct machine *
Signature · 1 line
1.7.9.5
PATCH v2 5/16 perf, tools: Add arbitary aliases and support names with -
In reply to Stephane EranianFrom: Andi Kleen <[email protected]>
- Add missing scanner symbol for arbitrary aliases inside the config region.
- looks nicer than _, so allow - in the event names. Used for various of the arch perfmon and Haswell events.
--- tools/perf/util/parse-events.l | 2 ++ 1 file changed, 2 insertions(+)
tools/perf/util/parse-events.l +2 -0
@@ -81,6 +81,7 @@ num_dec [0-9]+ num_hex 0x[a-fA-F0-9]+ num_raw_hex [a-fA-F0-9]+ name [a-zA-Z_*?][a-zA-Z0-9_*?]* +name_minus [a-zA-Z_*?][a-zA-Z0-9\-_*?]* modifier_event [ukhpGH]{1,8} modifier_bp [rwx]{1,3}
@@ -168,6 +169,7 @@ period { return term(yyscanner, PARSE_EVENTS__TERM_TYPE_SAMPLE_PERIOD); } branch_type { return term(yyscanner, PARSE_EVENTS__TERM_TYPE_BRANCH_SAMPLE_TYPE); } , { return ','; } "/" { BEGIN(INITIAL); return '/'; } +{name_minus} { return str(yyscanner, PE_NAME); } } mem: { BEGIN(mem); return PE_PREFIX_MEM; }
Signature · 1 line
1.7.9.5
[tip:perf/core] perf tools: Add arbitary aliases and support names with -
Commit-ID: eef9ba98b9ee96f52e544b09f581c397d8cc8265 Gitweb: http://git.kernel.org/tip/eef9ba98b9ee96f52e544b09f581c397d8cc8265 Author: Andi Kleen <[email protected]> AuthorDate: Mon, 5 Nov 2012 14:50:52 +0100 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Thu, 8 Nov 2012 16:12:03 -0300
perf tools: Add arbitary aliases and support names with -
- Add missing scanner symbol for arbitrary aliases inside the config region.
- looks nicer than _, so allow - in the event names. Used for various of the arch perfmon and Haswell events.
--- tools/perf/util/parse-events.l | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
tools/perf/util/parse-events.l +2 -0
@@ -81,6 +81,7 @@ num_dec [0-9]+ num_hex 0x[a-fA-F0-9]+ num_raw_hex [a-fA-F0-9]+ name [a-zA-Z_*?][a-zA-Z0-9_*?]* +name_minus [a-zA-Z_*?][a-zA-Z0-9\-_*?]* modifier_event [ukhpGH]{1,8} modifier_bp [rwx]{1,3}
@@ -168,6 +169,7 @@ period { return term(yyscanner, PARSE_EVENTS__TERM_TYPE_SAMPLE_PERIOD); } branch_type { return term(yyscanner, PARSE_EVENTS__TERM_TYPE_BRANCH_SAMPLE_TYPE); } , { return ','; } "/" { BEGIN(INITIAL); return '/'; } +{name_minus} { return str(yyscanner, PE_NAME); } } mem: { BEGIN(mem); return PE_PREFIX_MEM; }
PATCH v2 6/16 perf: add support for PERF_SAMPLE_ADDR in dump_sampple()
In reply to Stephane EranianWas missing from current code yet PERF_SAMPLE_ADDR has been present for a long time. Needed for PEBS-LL mode.
--- tools/perf/util/session.c | 4 ++++ 1 file changed, 4 insertions(+)
tools/perf/util/session.c +4 -0
@@ -1009,6 +1009,10 @@ static void dump_sample(struct perf_evsel *evsel, union perf_event *event,if (sample_type &PERF_SAMPLE_WEIGHT )printf (" ... weight: %" PRIu64"\n" , sample->weight); + +if (sample_type &PERF_SAMPLE_ADDR ) +printf (" ..... data: 0x%" PRIx64"\n" , sample->addr); + } static struct machine *
Signature · 1 line
1.7.9.5
PATCH v2 7/16 perf: add generic memory sampling interface
In reply to Stephane EranianThis patch adds PERF_SAMPLE_COST and PERF_SAMPLE_DSRC. The first collects a cost associated with the sampled event. In case of memory access, the cost would be the latency of the load, otherwise it defaults to the sampling period.
PERF_SAMPLE_DSRC collects the data source, i.e., where did the data associated with the sampled instruction come from. Information is stored in a perf_mem_dsrc structure. It contains opcode, mem level, tlb, snoop, lock information, subject to availability in hardware.
--- include/linux/perf_event.h | 2 ++ include/uapi/linux/perf_event.h | 69 +++++++++++++++++++++++++++++++++++++-- kernel/events/core.c | 6 ++++ 3 files changed, 75 insertions(+), 2 deletions(-)
include/linux/perf_event.h +2 -0
@@ -579,6 +579,7 @@ struct perf_sample_data {u32 reserved; } cpu_entry;u64 period; +union perf_mem_dsrc dsrc;struct perf_callchain_entry *callchain;struct perf_raw_record *raw;struct perf_branch_stack *br_stack;
@@ -599,6 +600,7 @@ static inline void perf_sample_data_init(struct perf_sample_data *data, data->regs_user.regs =NULL ; data->stack_user_size =0 ; data->weight =0 ; + data->dsrc.val =0 ; } extern void perf_output_sample(struct perf_output_handle *handle,
include/uapi/linux/perf_event.h +67 -2
86 lines not on this page · raw message
kernel/events/core.c +6 -0
@@ -958,6 +958,9 @@ static void perf_event__header_size(struct perf_event *event)if (sample_type &PERF_SAMPLE_READ ) size += event->read_size; +if (sample_type &PERF_SAMPLE_DSRC ) + size +=sizeof (data->dsrc.val); + event->header_size = size; }
@@ -4175,6 +4178,9 @@ void perf_output_sample(struct perf_output_handle *handle,perf_output_sample_ustack (handle, data->stack_user_size, data->regs_user.regs); + +if (sample_type &PERF_SAMPLE_DSRC ) +perf_output_put (handle, data->dsrc.val); } void perf_prepare_sample(struct perf_event_header *header,
Signature · 1 line
1.7.9.5
PATCH v2 8/16 perf/x86: add memory profiling via PEBS Load Latency
In reply to Stephane EranianThis patch adds support for memory profiling using the PEBS Load Latency facility.
Load accesses are sampled by HW and the instruction address, data address, load latency, data source, tlb, locked information can be saved in the sampling buffer if using the PERF_SAMPLE_COST (for latency), PERF_SAMPLE_ADDR, PERF_SAMPLE_DSRC types.
To enable PEBS Load Latency, users have to use the model specific event:
- on NHM/WSM: MEM_INST_RETIRED:LATENCY_ABOVE_THRESHOLD
- on SNB/IVB: MEM_TRANS_RETIRED:LATENCY_ABOVE_THRESHOLD
To make things easier, this patch also exports a generic alias via sysfs: mem-loads. It export the right event encoding based on the host CPU and can be used directly by the perf tool.
Loosely based on Intel's Lin Ming patch posted on LKML in July 2011.
--- arch/x86/include/asm/msr-index.h | 1 + arch/x86/kernel/cpu/perf_event.c | 3 + arch/x86/kernel/cpu/perf_event.h | 22 ++++- arch/x86/kernel/cpu/perf_event_intel.c | 56 ++++++++++++ arch/x86/kernel/cpu/perf_event_intel_ds.c | 133 +++++++++++++++++++++++++++-- 5 files changed, 206 insertions(+), 9 deletions(-)
arch/x86/include/asm/msr-index.h +1 -0
@@ -66,6 +66,7 @@#define MSR_IA32_PEBS_ENABLE 0x000003f1#define MSR_IA32_DS_AREA 0x00000600#define MSR_IA32_PERF_CAPABILITIES 0x00000345 +#define MSR_PEBS_LD_LAT_THRESHOLD 0x000003f6#define MSR_MTRRfix64K_00000 0x00000250#define MSR_MTRRfix16K_80000 0x00000258
arch/x86/kernel/cpu/perf_event.c +3 -0
@@ -1475,6 +1475,9 @@ static int __init init_hw_perf_events(void) x86_pmu.attr_rdpmc =1 ;/* enable userspace RDPMC usage by default */ x86_pmu_format_group.attrs = x86_pmu.format_attrs; +if (x86_pmu.event_attrs) + x86_pmu_events_group.attrs = x86_pmu.event_attrs; +if (!x86_pmu.events_sysfs_show) x86_pmu_events_group.attrs = &empty_attrs;else
arch/x86/kernel/cpu/perf_event.h +21 -1
@@ -46,6 +46,7 @@ enum extra_reg_type {EXTRA_REG_RSP_0 =0 ,/* offcore_response_0 */ EXTRA_REG_RSP_1 =1 ,/* offcore_response_1 */ EXTRA_REG_LBR =2 ,/* lbr_select */ +EXTRA_REG_LDLAT =3 ,/* ld_lat_threshold */ EXTRA_REG_MAX /* number of entries needed */ };
@@ -61,6 +62,10 @@ struct event_constraint {int overlap;int flags; }; +/* +* struct event_constraint flags +*/ +#define PERF_X86_EVENT_PEBS_LDLAT 0x1/* ld+ldlat data address sampling */ struct amd_nb {int nb_id;/* NorthBridge id */
@@ -233,6 +238,10 @@ struct cpu_hw_events {#define INTEL_UEVENT_CONSTRAINT (c, n) \ EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK) +#define INTEL_PLD_CONSTRAINT (c, n) \ + __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK, \ + HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_LDLAT) +#define EVENT_CONSTRAINT_END \ EVENT_CONSTRAINT(0, 0, 0)
@@ -262,12 +271,22 @@ struct extra_reg { .msr = (ms), \ .config_mask = (m), \ .valid_mask = (vm), \ - .idx = EXTRA_REG_##i \ + .idx = EXTRA_REG_##i, \ }#define INTEL_EVENT_EXTRA_REG (event, msr, vm, idx) \ EVENT_EXTRA_REG(event, msr, ARCH_PERFMON_EVENTSEL_EVENT, vm, idx) +#define INTEL_UEVENT_EXTRA_REG (event, msr, vm, idx) \ + EVENT_EXTRA_REG(event, msr, ARCH_PERFMON_EVENTSEL_EVENT | \ + ARCH_PERFMON_EVENTSEL_UMASK, vm, idx) + +#define INTEL_UEVENT_PEBS_LDLAT_EXTRA_REG (c) \ + INTEL_UEVENT_EXTRA_REG(c, \ + MSR_PEBS_LD_LAT_THRESHOLD, \ + 0xffff, \ + LDLAT) +#define EVENT_EXTRA_END EVENT_EXTRA_REG(0, 0, 0, 0, RSP_0)union perf_capabilities {
@@ -355,6 +374,7 @@ struct x86_pmu {*/ int attr_rdpmc;struct attribute **format_attrs; +struct attribute **event_attrs;ssize_t (*events_sysfs_show)(char *page,u64 config);
arch/x86/kernel/cpu/perf_event_intel.c +56 -0
101 lines not on this page · raw message
arch/x86/kernel/cpu/perf_event_intel_ds.c +125 -8
185 lines not on this page · raw message
Signature · 1 line
1.7.9.5
Re: [PATCH v2 08/16] perf/x86: add memory profiling via PEBS Load Latency
arch/x86/kernel/cpu/perf_event_intel.c static struct event_constraint intel_gen_event_constraints[] __read_mostly = · line 149
Quoted 10 lines
arch/x86/kernel/cpu/perf_event_intel.c +10
-0+EVENT_ATTR (cpu-cycles,CPU_CYCLES ); +EVENT_ATTR (instructions,INSTRUCTIONS ); +EVENT_ATTR (cache-references,CACHE_REFERENCES ); +EVENT_ATTR (cache-misses,CACHE_MISSES ); +EVENT_ATTR (branch-instructions,BRANCH_INSTRUCTIONS ); +EVENT_ATTR (branch-misses,BRANCH_MISSES ); +EVENT_ATTR (bus-cycles,BUS_CYCLES ); +EVENT_ATTR (stalled-cycles-frontend,STALLED_CYCLES_FRONTEND ); +EVENT_ATTR (stalled-cycles-backend,STALLED_CYCLES_BACKEND ); +EVENT_ATTR (ref-cycles,REF_CPU_CYCLES );
The merge_events() approach from the Haswell patches should be far cleaner
-Andi
Signature · 1 line
[email protected] -- Speaking for myself only
Re: [PATCH v2 08/16] perf/x86: add memory profiling via PEBS Load Latency
Quoted 4 lines · Andi Kleen
Quoted 4 lines
arch/x86/kernel/cpu/perf_event_intel.c +4
-0+EVENT_ATTR (cpu-cycles,CPU_CYCLES ); +EVENT_ATTR (instructions,INSTRUCTIONS ); +EVENT_ATTR (cache-references,CACHE_REFERENCES ); +EVENT_ATTR (cache-misses,CACHE_MISSES );
Quoted 9 lines
arch/x86/kernel/cpu/perf_event_intel.c static struct event_constraint intel_gen_event_constraints[] __read_mostly = · line 149
Quoted 6 lines
arch/x86/kernel/cpu/perf_event_intel.c +6
-0+EVENT_ATTR (branch-instructions,BRANCH_INSTRUCTIONS ); +EVENT_ATTR (branch-misses,BRANCH_MISSES ); +EVENT_ATTR (bus-cycles,BUS_CYCLES ); +EVENT_ATTR (stalled-cycles-frontend,STALLED_CYCLES_FRONTEND ); +EVENT_ATTR (stalled-cycles-backend,STALLED_CYCLES_BACKEND ); +EVENT_ATTR (ref-cycles,REF_CPU_CYCLES );The
merge_events()approach from the Haswell patches should be far cleaner
And which patch in your HSW series implements this?
Quoted 4 lines
-Andi
--
[email protected] -- Speaking for myself only
Re: [PATCH v2 08/16] perf/x86: add memory profiling via PEBS Load Latency
Quoted 14 lines · Stephane Eranian
Quoted 4 lines · Andi Kleen
Quoted 4 lines
arch/x86/kernel/cpu/perf_event_intel.c +4
-0+EVENT_ATTR (cpu-cycles,CPU_CYCLES ); +EVENT_ATTR (instructions,INSTRUCTIONS ); +EVENT_ATTR (cache-references,CACHE_REFERENCES ); +EVENT_ATTR (cache-misses,CACHE_MISSES );Quoted 9 lines
arch/x86/kernel/cpu/perf_event_intel.c static struct event_constraint intel_gen_event_constraints[] __read_mostly = · line 149
Quoted 6 lines
arch/x86/kernel/cpu/perf_event_intel.c +6
-0+EVENT_ATTR (branch-instructions,BRANCH_INSTRUCTIONS ); +EVENT_ATTR (branch-misses,BRANCH_MISSES ); +EVENT_ATTR (bus-cycles,BUS_CYCLES ); +EVENT_ATTR (stalled-cycles-frontend,STALLED_CYCLES_FRONTEND ); +EVENT_ATTR (stalled-cycles-backend,STALLED_CYCLES_BACKEND ); +EVENT_ATTR (ref-cycles,REF_CPU_CYCLES );The
merge_events()approach from the Haswell patches should be far cleaner
Quoted 1 line
And which patch in your HSW series implements this?
[PATCH 27/32] perf, x86: Support CPU specific sysfs events
-Andi
Signature · 1 line
[email protected] -- Speaking for myself only
Re: [PATCH v2 08/16] perf/x86: add memory profiling via PEBS Load Latency
Quoted 15 lines · Andi Kleen
Quoted 14 lines · Stephane Eranian
Quoted 13 lines · Andi Kleen
arch/x86/kernel/cpu/perf_event_intel.c static struct event_constraint intel_gen_event_constraints[] __read_mostly = · line 149
Quoted 10 lines
arch/x86/kernel/cpu/perf_event_intel.c +10
-0+EVENT_ATTR (cpu-cycles,CPU_CYCLES ); +EVENT_ATTR (instructions,INSTRUCTIONS ); +EVENT_ATTR (cache-references,CACHE_REFERENCES ); +EVENT_ATTR (cache-misses,CACHE_MISSES ); +EVENT_ATTR (branch-instructions,BRANCH_INSTRUCTIONS ); +EVENT_ATTR (branch-misses,BRANCH_MISSES ); +EVENT_ATTR (bus-cycles,BUS_CYCLES ); +EVENT_ATTR (stalled-cycles-frontend,STALLED_CYCLES_FRONTEND ); +EVENT_ATTR (stalled-cycles-backend,STALLED_CYCLES_BACKEND ); +EVENT_ATTR (ref-cycles,REF_CPU_CYCLES );The
merge_events()approach from the Haswell patches should be far cleaner
Quoted 4 lines
Quoted 1 line
And which patch in your HSW series implements this?
[PATCH 27/32] perf, x86: Support CPU specific sysfs events
Will try using that one.
Thanks.
Re: [PATCH v2 08/16] perf/x86: add memory profiling via PEBS Load Latency
Quoted 17 lines · Stephane Eranian
Quoted 15 lines · Andi Kleen
Quoted 14 lines · Stephane Eranian
Quoted 13 lines · Andi Kleen
arch/x86/kernel/cpu/perf_event_intel.c static struct event_constraint intel_gen_event_constraints[] __read_mostly = · line 149
Quoted 10 lines
arch/x86/kernel/cpu/perf_event_intel.c +10
-0+EVENT_ATTR (cpu-cycles,CPU_CYCLES ); +EVENT_ATTR (instructions,INSTRUCTIONS ); +EVENT_ATTR (cache-references,CACHE_REFERENCES ); +EVENT_ATTR (cache-misses,CACHE_MISSES ); +EVENT_ATTR (branch-instructions,BRANCH_INSTRUCTIONS ); +EVENT_ATTR (branch-misses,BRANCH_MISSES ); +EVENT_ATTR (bus-cycles,BUS_CYCLES ); +EVENT_ATTR (stalled-cycles-frontend,STALLED_CYCLES_FRONTEND ); +EVENT_ATTR (stalled-cycles-backend,STALLED_CYCLES_BACKEND ); +EVENT_ATTR (ref-cycles,REF_CPU_CYCLES );The
merge_events()approach from the Haswell patches should be far cleaner
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
And which patch in your HSW series implements this?
[PATCH 27/32] perf, x86: Support CPU specific sysfs events
Ok, integrated that patch in my series and changed my code to use it. It works.
PATCH v2 9/16 perf/x86: export PEBS load latency threshold register to sysfs
In reply to Stephane EranianMake the PEBS Load Latency threshold register layout and encoding visible to user level tools.
--- arch/x86/kernel/cpu/perf_event_intel.c | 3 +++ 1 file changed, 3 insertions(+)
arch/x86/kernel/cpu/perf_event_intel.c +3 -0
@@ -1787,6 +1787,8 @@ static void intel_pmu_flush_branch_stack(void)PMU_FORMAT_ATTR (offcore_rsp,"config1:0-63" ); +PMU_FORMAT_ATTR (ldlat,"config1:0-15" ); +static struct attribute *intel_arch3_formats_attr[] = { &format_attr_event.attr, &format_attr_umask.attr,
@@ -1797,6 +1799,7 @@ static struct attribute *intel_arch3_formats_attr[] = { &format_attr_cmask.attr, &format_attr_offcore_rsp.attr,/* XXX do NHM/WSM + SNB breakout */ + &format_attr_ldlat.attr,/* PEBS load latency */ NULL, };
Signature · 1 line
1.7.9.5
PATCH v2 10/16 perf/x86: add support for PEBS Precise Store
In reply to Stephane EranianThis patch adds support for PEBS Precise Store which is available on Intel Sandy Bridge and Ivy Bridge processors.
To use Precise store, the proper PEBS event must be used: mem_trans_retired:precise_stores. For the perf tool, the generic mem-stores event exported via sysfs can be used directly.
--- arch/x86/kernel/cpu/perf_event.h | 5 +++ arch/x86/kernel/cpu/perf_event_intel.c | 2 ++ arch/x86/kernel/cpu/perf_event_intel_ds.c | 49 +++++++++++++++++++++++++++-- 3 files changed, 54 insertions(+), 2 deletions(-)
arch/x86/kernel/cpu/perf_event.h +5 -0
@@ -66,6 +66,7 @@ struct event_constraint {* struct event_constraint flags */ #define PERF_X86_EVENT_PEBS_LDLAT 0x1/* ld+ldlat data address sampling */ +#define PERF_X86_EVENT_PEBS_ST 0x2/* st data address sampling */ struct amd_nb {int nb_id;/* NorthBridge id */
@@ -242,6 +243,10 @@ struct cpu_hw_events {__EVENT_CONSTRAINT (c, n,INTEL_ARCH_EVENT_MASK , \ HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_LDLAT) +#define INTEL_PST_CONSTRAINT (c, n) \ + __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK, \ + HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_ST) +#define EVENT_CONSTRAINT_END \ EVENT_CONSTRAINT(0, 0, 0)
arch/x86/kernel/cpu/perf_event_intel.c +2 -0
@@ -150,6 +150,7 @@ EVENT_ATTR(ref-cycles, REF_CPU_CYCLES );EVENT_ATTR_STR (mem-loads, mem_ld_nhm,"event=0x0b,umask=0x10,ldlat=3" );EVENT_ATTR_STR (mem-loads, mem_ld_snb,"event=0xcd,umask=0x1,ldlat=3" ); +EVENT_ATTR_STR (mem-stores, mem_st_snb,"event=0xcd,umask=0x2" );struct attribute *nhm_events_attrs[] = {EVENT_PTR (CPU_CYCLES ),
@@ -178,6 +179,7 @@ struct attribute *snb_events_attrs[] = {EVENT_PTR (STALLED_CYCLES_BACKEND ),EVENT_PTR (REF_CPU_CYCLES ),EVENT_PTR (mem_ld_snb), +EVENT_PTR (mem_st_snb), NULL, };
arch/x86/kernel/cpu/perf_event_intel_ds.c +47 -2
96 lines not on this page · raw message
Signature · 1 line
1.7.9.5
PATCH v2 11/16 perf tools: add mem access sampling core support
In reply to Stephane EranianThis patch adds the sorting and histogram support
functions to enable profiling of memory accesses.
The following sorting orders are added:
- symbol_daddr: data address symbol (or raw address)
- dso_daddr: data address shared object
- cost: access cost
- locked: access uses locked transaction
- tlb : TLB access
- mem : memory level of the access (L1, L2, L3, RAM, ...)
- snoop: access snoop mode
--- tools/perf/util/event.h | 1 + tools/perf/util/evsel.c | 4 + tools/perf/util/hist.c | 66 ++++++++- tools/perf/util/hist.h | 13 ++ tools/perf/util/session.c | 37 ++++++ tools/perf/util/session.h | 4 + tools/perf/util/sort.c | 324 ++++++++++++++++++++++++++++++++++++++++++++- tools/perf/util/sort.h | 10 +- tools/perf/util/symbol.h | 7 + 9 files changed, 456 insertions(+), 10 deletions(-)
tools/perf/util/event.h +1 -0
@@ -91,6 +91,7 @@ struct perf_sample {u32 cpu;u32 raw_size;u64 weight; +u64 dsrc;void *raw_data;struct ip_callchain *callchain;struct branch_stack *branch_stack;
tools/perf/util/evsel.c +4 -0
@@ -1025,6 +1025,10 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel, union perf_event *event, array++; } +if (type &PERF_SAMPLE_DSRC ) { + data->dsrc = *array; + array++; + }return 0 ; }
tools/perf/util/hist.c +63 -3
114 lines not on this page · raw message
tools/perf/util/hist.h +13 -0
@@ -48,6 +48,13 @@ enum hist_column {HISTC_DSO_FROM ,HISTC_DSO_TO ,HISTC_SRCLINE , +HISTC_MEM_DADDR_SYMBOL , +HISTC_MEM_DADDR_DSO , +HISTC_MEM_COST , +HISTC_MEM_LOCKED , +HISTC_MEM_TLB , +HISTC_MEM_LVL , +HISTC_MEM_SNOOP , HISTC_NR_COLS, /* Last entry */ };
@@ -85,6 +92,12 @@ struct hist_entry *__hists__add_branch_entry(struct hists *self,struct branch_info *bi, u64 period); +struct hist_entry *__hists__add_mem_entry (struct hists *self, +struct addr_location *al, +struct symbol *sym_parent, +struct mem_info *mi, +u64 period); +void hists__output_resort (struct hists *self);void hists__output_resort_threaded (struct hists *hists);void hists__collapse_resort (struct hists *self);
tools/perf/util/session.c +37 -0
@@ -273,6 +273,41 @@ static void ip__resolve_ams(struct machine *self, struct thread *thread, ams->map = al.map; } +static void ip__resolve_data (struct machine *self,struct thread *thread, +u8 m, +struct addr_map_symbol *ams, +u64 addr) +{ +struct addr_location al; + +memset (&al,0 ,sizeof (al)); + +thread__find_addr_location (thread, self, m,MAP__VARIABLE , addr, &al,NULL ); + ams->addr = addr; + ams->al_addr = al.addr; + ams->sym = al.sym; + ams->map = al.map; +} + +struct mem_info *machine__resolve_mem (struct machine *self, +struct thread *thr, +struct perf_sample *sample, +u8 cpumode) +{ +struct mem_info *mi; + + mi =calloc (1 ,sizeof (struct mem_info )); +if (!mi) +return NULL ; + +ip__resolve_ams (self, thr, &mi->iaddr, sample->ip); +ip__resolve_data (self, thr, cpumode, &mi->daddr, sample->addr); + mi->cost = sample->weight; + mi->dsrc.val = sample->dsrc; + +return mi; +} +struct branch_info *machine__resolve_bstack (struct machine *self,struct thread *thr,struct branch_stack *bs)
@@ -1013,6 +1048,8 @@ static void dump_sample(struct perf_evsel *evsel, union perf_event *event,if (sample_type &PERF_SAMPLE_ADDR )printf (" ..... data: 0x%" PRIx64"\n" , sample->addr); +if (sample_type &PERF_SAMPLE_DSRC ) +printf (" . data_src: 0x%" PRIx64"\n" , sample->dsrc); } static struct machine *
tools/perf/util/session.h +4 -0
@@ -72,6 +72,10 @@ struct branch_info *machine__resolve_bstack(struct machine *self,struct thread *thread, struct branch_stack *bs); +struct mem_info *machine__resolve_mem (struct machine *self, +struct thread *thread, +struct perf_sample *sample,u8 cpumode); +bool perf_session__has_traces (struct perf_session *self,const char *msg);void mem_bswap_64 (void *src,int byte_size);
tools/perf/util/sort.c +318 -6
360 lines not on this page · raw message
tools/perf/util/sort.h +9 -1
@@ -102,7 +102,8 @@ struct hist_entry { };struct branch_info *branch_info;struct hists *hists; -struct callchain_root callchain[0 ]; +struct mem_info *mem_info; +struct callchain_root callchain[0 ];/* must be last member */ };enum sort_type {
@@ -118,6 +119,13 @@ enum sort_type {SORT_SYM_TO ,SORT_MISPREDICT ,SORT_SRCLINE , +SORT_MEM_DADDR_SYMBOL , +SORT_MEM_DADDR_DSO , +SORT_MEM_COST , +SORT_MEM_LOCKED , +SORT_MEM_TLB , +SORT_MEM_LVL , + SORT_MEM_SNOOP, };/*
tools/perf/util/symbol.h +7 -0
@@ -152,6 +152,13 @@ struct branch_info {struct branch_flags flags; }; +struct mem_info { +struct addr_map_symbol iaddr; +struct addr_map_symbol daddr; +u64 cost; +union perf_mem_dsrc dsrc; +}; +struct addr_location {struct thread *thread;struct map *map;
Signature · 1 line
1.7.9.5
PATCH v2 12/16 perf report: add support for mem access profiling
In reply to Stephane EranianThis patch adds the --mem-mode option to perf report.
This mode requires a perf.data file created with memory access samples.
--- tools/perf/builtin-report.c | 131 +++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 127 insertions(+), 4 deletions(-)
tools/perf/builtin-report.c +127 -4
@@ -46,6 +46,7 @@ struct perf_report {bool show_full_info;bool show_threads;bool inverted_callchain; +bool mem_mode;struct perf_read_values show_threads_values;const char *pretty_printing_style;symbol_filter_t annotate_init;
@@ -54,6 +55,96 @@ struct perf_report {DECLARE_BITMAP (cpu_bitmap,MAX_NR_CPUS ); }; +static int perf_report__add_mem_hist_entry (struct perf_tool *tool, +struct addr_location *al, +struct perf_sample *sample, +struct perf_evsel *evsel, +struct machine *machine, +union perf_event *event) +{ + struct perf_report *rep = container_of(tool, struct perf_report, tool); +struct symbol *parent =NULL ; +u8 cpumode = event->header.misc &PERF_RECORD_MISC_CPUMODE_MASK ; +int err =0 ; +struct hist_entry *he; +struct mem_info *mi, *mx; +uint64_t cost; + +if ((sort__has_parent || symbol_conf.use_callchain) + && sample->callchain) { + err =machine__resolve_callchain (machine, evsel, al->thread, + sample, &parent); +if (err) +return err; + } + + mi =machine__resolve_mem (machine, al->thread, sample, cpumode); +if (!mi) +return -ENOMEM ; + +if (rep->hide_unresolved && !al->sym) +return 0 ; + + cost = mi->cost; +if (!cost) + cost =1 ; + +/* +* The report shows the percentage of total branches captured +* and not events sampled. Thus we use a pseudo period of 1. +* Only in the newt browser we are doing integrated annotation, +* so we don't allocated the extra space needed because the stdio +* code will not use it. +*/ + he =__hists__add_mem_entry (&evsel->hists, al, parent, mi, + cost); +if (!he) +return -ENOMEM ; + +if (sort__has_sym && he->ms.sym && use_browser >0 ) { +struct annotation *notes =symbol__annotation (he->ms.sym); + +assert (evsel !=NULL ); + +if (notes->src ==NULL &&symbol__alloc_hist (he->ms.sym) <0 ) + goto out; + + err =hist_entry__inc_addr_samples (he, evsel->idx, al->addr); +if (err) + goto out; + } + +if (sort__has_sym && he->mem_info->daddr.sym && use_browser >0 ) { +struct annotation *notes; + + mx = he->mem_info; + + notes =symbol__annotation (mx->daddr.sym); +if (!notes->src + &&symbol__alloc_hist (mx->daddr.sym) <0 ) + goto out; + + err =symbol__inc_addr_samples (mx->daddr.sym, + mx->daddr.map, + evsel->idx, + mx->daddr.al_addr); +if (err) + goto out; + } + + evsel->hists.stats.total_period += sample->period; +hists__inc_nr_events (&evsel->hists,PERF_RECORD_SAMPLE ); + err =0 ; + +if (symbol_conf.use_callchain) { + err =callchain_append (he->callchain, + &callchain_cursor, + sample->period); + } +out: +return err; +} + static int perf_report__add_branch_hist_entry(struct perf_tool *tool, struct addr_location *al, struct perf_sample *sample,
@@ -209,6 +300,12 @@ static int process_sample_event(struct perf_tool *tool,pr_debug ("problem adding lbr entry, skipping event\n" );return -1 ; } + }else if (rep->mem_mode ==1 ) { +if (perf_report__add_mem_hist_entry (tool, &al, sample, + evsel, machine, event)) { +pr_debug ("problem adding mem entry, skipping event\n" ); +return -1 ; + } }else {if (al.map !=NULL ) al.map->dso->hit =1 ;
@@ -292,7 +389,8 @@ static void sig_handler(int sig __maybe_unused) session_done =1 ; } -static size_t hists__fprintf_nr_sample_events (struct hists *self, +static size_t hists__fprintf_nr_sample_events (struct perf_report *rep, +struct hists *self,const char *evname,FILE *fp) {size_t ret;
@@ -305,7 +403,11 @@ static size_t hists__fprintf_nr_sample_events(struct hists *self,if (evname !=NULL ) ret +=fprintf (fp," of event '%s'" , evname); - ret +=fprintf (fp,"\n# Event count (approx.): %" PRIu64, nr_events); +if (rep->mem_mode) { + ret +=fprintf (fp,"\n# Total cost : %" PRIu64, nr_events); + ret +=fprintf (fp,"\n# Sort order : %s" , sort_order); + }else + ret +=fprintf (fp,"\n# Event count (approx.): %" PRIu64, nr_events);return ret +fprintf (fp,"\n#\n" ); }
@@ -319,7 +421,7 @@ static int perf_evlist__tty_browse_hists(struct perf_evlist *evlist,struct hists *hists = &pos->hists;const char *evname =perf_evsel__name (pos); -hists__fprintf_nr_sample_events (hists, evname, stdout); +hists__fprintf_nr_sample_events (rep, hists, evname, stdout);hists__fprintf (hists, true,0 ,0 , stdout);fprintf (stdout,"\n\n" ); }
@@ -595,7 +697,7 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused) "Use the stdio interface"),OPT_STRING ('s' ,"sort" , &sort_order,"key[,key2...]" ,"sort by key(s): pid, comm, dso, symbol, parent, dso_to," -" dso_from, symbol_to, symbol_from, mispredict" ), +" dso_from, symbol_to, symbol_from, mispredict, mem, cost, symbol_daddr, dso_daddr, tlb, snoop, locked" ),OPT_BOOLEAN (0 ,"showcpuutilization" , &symbol_conf.show_cpu_utilization,"Show sample percentage for different cpu modes" ), OPT_STRING('p', "parent", &parent_pattern, "regex",
@@ -641,6 +743,7 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused) "use branch records for histogram filling", parse_branch_mode),OPT_STRING (0 ,"objdump" , &objdump_path,"path" ,"objdump binary to use for disassembly and annotations" ), +OPT_BOOLEAN (0 ,"mem-mode" , &report.mem_mode,"mem access profile" ), OPT_END() };
@@ -692,6 +795,18 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)"dso_to,symbol_to" ; } +if (report.mem_mode) { +if (sort__branch_mode ==1 ) { +fprintf (stderr,"branch and mem mode incompatible\n" ); + goto error; + } +/* +* if no sort_order is provided, then specify +* branch-mode specific order +*/ +if (sort_order == default_sort_order) + sort_order ="cost,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked" ; + }if (strcmp (input_name,"-" ) !=0 )setup_browser (true);
@@ -763,6 +878,14 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)sort_entry__setup_elide (&sort_sym_from, symbol_conf.sym_from_list,"sym_from" , stdout);sort_entry__setup_elide (&sort_sym_to, symbol_conf.sym_to_list,"sym_to" , stdout); }else { +if (report.mem_mode) { +sort_entry__setup_elide (&sort_dso, symbol_conf.dso_list,"symbol_daddr" , stdout); +sort_entry__setup_elide (&sort_dso, symbol_conf.dso_list,"dso_daddr" , stdout); +sort_entry__setup_elide (&sort_dso, symbol_conf.dso_list,"mem" , stdout); +sort_entry__setup_elide (&sort_dso, symbol_conf.dso_list,"cost" , stdout); +sort_entry__setup_elide (&sort_dso, symbol_conf.dso_list,"tlb" , stdout); +sort_entry__setup_elide (&sort_dso, symbol_conf.dso_list,"snoop" , stdout); + }sort_entry__setup_elide (&sort_dso, symbol_conf.dso_list,"dso" , stdout);sort_entry__setup_elide (&sort_sym, symbol_conf.sym_list,"symbol" , stdout); }
Signature · 1 line
1.7.9.5
PATCH v2 13/16 perf record: add support for mem access profiling
In reply to Stephane EranianAdd the -l option to perf record to enable sampling access cost sampling.
Data address sampling is obtained via the -d option.
--- tools/perf/builtin-record.c | 2 ++ tools/perf/perf.h | 1 + tools/perf/util/evsel.c | 6 ++++++ 3 files changed, 9 insertions(+)
tools/perf/builtin-record.c +2 -0
@@ -1041,6 +1041,8 @@ const struct option record_options[] = {OPT_CALLBACK ('j' ,"branch-filter" , &record.opts.branch_stack,"branch filter mask" ,"branch stack filter modes" , parse_branch_stack), +OPT_BOOLEAN ('l' ,"cost" , &record.opts.weight, +"event cost" ), OPT_END() };
tools/perf/perf.h +1 -0
@@ -237,6 +237,7 @@ struct perf_record_opts {bool sample_id_all_missing;bool exclude_guest_missing;bool period; +bool weight;unsigned int freq;unsigned int mmap_pages;unsigned int user_freq;
tools/perf/util/evsel.c +6 -0
@@ -474,6 +474,12 @@ void perf_evsel__config(struct perf_evsel *evsel, struct perf_record_opts *opts, attr->sample_type |=PERF_SAMPLE_CPU ; } +if (opts->weight) + attr->sample_type |=PERF_SAMPLE_WEIGHT ; + +if (opts->sample_address) + attr->sample_type |=PERF_SAMPLE_DSRC ; +if (opts->no_delay) { attr->watermark =0 ; attr->wakeup_events =1 ;
Signature · 1 line
1.7.9.5
PATCH v2 14/16 perf tools: add new mem command for memory access profiling
In reply to Stephane EranianThis new command is a wrapper on top of perf record and perf report to make it easier to configure for memory access profiling.
To record loads:
$ perf mem -t load rec .....
To record stores:
$ perf mem -t store rec .....
To get the report:
$ perf mem -t load rep
--- tools/perf/Documentation/perf-mem.txt | 48 +++++++ tools/perf/Makefile | 1 + tools/perf/builtin-mem.c | 238 +++++++++++++++++++++++++++++++++ tools/perf/builtin.h | 1 + tools/perf/command-list.txt | 1 + tools/perf/perf.c | 1 + 6 files changed, 290 insertions(+) create mode 100644 tools/perf/Documentation/perf-mem.txt create mode 100644 tools/perf/builtin-mem.c
tools/perf/Documentation/perf-mem.txt new file +48 -0
@@ -0,0 +1,48 @@ +perf-mem(1) +=========== + +NAME +---- +perf-mem - Profile memory accesses + +SYNOPSIS +-------- +[verse] +'perf mem' [<options>] (record [<command>] | report) + +DESCRIPTION +----------- +"perf mem -t <TYPE> record" runs a command and gathers memory operation data +from it, into perf.data. Perf record options are accepted and are passed through. + +"perf mem -t <TYPE> report" displays the result. It invokes perf report with the +right set of options to display a memory access profile. + +OPTIONS +------- +<command>...:: + Any command you can specify in a shell. + +-t:: +--type=:: + Select the memory operation type: load or store (default: load) + +-D:: +--dump-raw-samples=:: + Dump the raw decoded samples on the screen in a format that is easy to parse with + one sample per line. + +-x:: +--field-separator:: + Specify the field separator used when dump raw samples (-D option). By default, + The separator is the space character. + +-C:: +--cpu-list:: + Restrict dump of raw samples to those provided via this option. Note that the same + option can be passed in record mode. It will be interpreted the same way as perf + record. + +SEE ALSO +-------- +linkperf:perf-record[1], linkperf:perf-report[1]
tools/perf/Makefile +1 -0
@@ -461,6 +461,7 @@ BUILTIN_OBJS += $(OUTPUT)builtin-lock.o BUILTIN_OBJS += $(OUTPUT)builtin-kvm.o BUILTIN_OBJS += $(OUTPUT)builtin-test.o BUILTIN_OBJS += $(OUTPUT)builtin-inject.o +BUILTIN_OBJS += $(OUTPUT)builtin-mem.o PERFLIBS = $(LIB_FILE) $(LIBTRACEEVENT)
tools/perf/builtin-mem.c new file +238 -0
238 lines not on this page · raw message
tools/perf/builtin.h +1 -0
@@ -36,6 +36,7 @@ extern int cmd_kvm(int argc, const char **argv, const char *prefix);extern int cmd_test (int argc,const char **argv,const char *prefix);extern int cmd_trace (int argc,const char **argv,const char *prefix);extern int cmd_inject (int argc,const char **argv,const char *prefix); +extern int cmd_mem (int argc,const char **argv,const char *prefix);extern int find_scripts (char **scripts_array,char **scripts_path_array);#endif
tools/perf/command-list.txt +1 -0
@@ -24,3 +24,4 @@ perf-kmem mainporcelain common perf-lock mainporcelain common perf-kvm mainporcelain common perf-test mainporcelain common +perf-mem mainporcelain common
tools/perf/perf.c +1 -0
@@ -60,6 +60,7 @@ static struct cmd_struct commands[] = { { "trace", cmd_trace, 0 }, #endif { "inject", cmd_inject, 0 }, + { "mem", cmd_mem, 0 }, }; struct pager_config {
Signature · 1 line
1.7.9.5
Re: [PATCH v2 14/16] perf tools: add new mem command for memory access profiling
Em Mon, Nov 05, 2012 at 02:51:01PM +0100, Stephane Eranian escreveu:
tools/perf/builtin-mem.c line 51
Quoted 6 lines
tools/perf/builtin-mem.c new file +6
-0+ +if (strcmp (mem_operation,MEM_OPERATION_LOAD )) +sprintf (event,"cpu/mem-stores/pp" ); +else +sprintf (event,"cpu/mem-loads/pp" ); +
Fails for me on a Sandy Bridge notebook:
[root@sandy ~]# perf mem -t store record -a
Error:
'precise' request may not be supported. Try removing 'p' modifier
So if I manually fall back to a less precise mode:
[root@sandy ~]# perf record -g -a -e cpu/mem-stores/p Error:
'precise' request may not be supported. Try removing 'p' modifier [root@sandy ~]#
Still can't, manually fall back a one more level:
[root@sandy ~]# perf record -g -a -e cpu/mem-stores/
^C[ perf record: Woken up 25 times to write data ]
[ perf record: Captured and wrote 7.419 MB perf.data (~324160 samples) ]
Yay, got some numbers.
smpboot: CPU0: Intel(R) Core(TM) i7-2920XM CPU @ 2.50GHz (fam: 06, model: 2a, stepping: 07) Performance Events: PEBS fmt1+, 16-deep LBR, SandyBridge events, Intel PMU driver.perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode
... version: 3 ... bit width: 48 ... generic registers: 4 ... value mask: 0000ffffffffffff ... max period: 000000007fffffff ... fixed-purpose events: 3 ... event mask: 000000070000000f
Disabled fast string operations
NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
Do you have any test program you use to test if the results make sense that you could share?
I could then try to shape it into a new 'perf test' entry that would test if requesting this event and then doing synthetic testing would produce the experted numbers or in a acceptable range.
One suggestion for such new features, examples of use with the resulting output looks great on changeset logs :-)
Ah, I recall seeing some, but that was on the patchset cover letter, that doesn't get inserted in the git changelog history, will look at those now.
- Arnaldo
Re: [PATCH v2 14/16] perf tools: add new mem command for memory access profiling
Quoted 10 lines · Arnaldo Carvalho de Melo
Em Mon, Nov 05, 2012 at 02:51:01PM +0100, Stephane Eranian escreveu:
tools/perf/builtin-mem.c line 51
Quoted 6 lines
tools/perf/builtin-mem.c new file +6
-0+ +if (strcmp (mem_operation,MEM_OPERATION_LOAD )) +sprintf (event,"cpu/mem-stores/pp" ); +else +sprintf (event,"cpu/mem-loads/pp" ); +Fails for me on a Sandy Bridge notebook:
That's because you need to update the microcode.
$ sudo modprobe microcode $ cat /proc/cpuinfo
Line with microcode needs to say:
microcode : 0x28
update the microcode package or install directly from intel download center.
Quoted 47 lines
[root@sandy ~]# perf mem -t store record -a
Error:
'precise' request may not be supported. Try removing 'p' modifierSo if I manually fall back to a less precise mode:
[root@sandy ~]# perf record -g -a -e cpu/mem-stores/p Error:
'precise' request may not be supported. Try removing 'p' modifier [root@sandy ~]#Still can't, manually fall back a one more level:
[root@sandy ~]# perf record -g -a -e cpu/mem-stores/
^C[ perf record: Woken up 25 times to write data ]
[ perf record: Captured and wrote 7.419 MB perf.data (~324160 samples) ]Yay, got some numbers.
smpboot: CPU0: Intel(R) Core(TM) i7-2920XM CPU @ 2.50GHz (fam: 06, model: 2a, stepping: 07) Performance Events: PEBS fmt1+, 16-deep LBR, SandyBridge events, Intel PMU driver.
perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode... version: 3 ... bit width: 48 ... generic registers: 4 ... value mask: 0000ffffffffffff ... max period: 000000007fffffff ... fixed-purpose events: 3 ... event mask: 000000070000000fDisabled fast string operations
NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.Do you have any test program you use to test if the results make sense that you could share?
I could then try to shape it into a new 'perf test' entry that would test if requesting this event and then doing synthetic testing would produce the experted numbers or in a acceptable range.
One suggestion for such new features, examples of use with the resulting output looks great on changeset logs :-)
Ah, I recall seeing some, but that was on the patchset cover letter, that doesn't get inserted in the git changelog history, will look at those now.
- Arnaldo
Re: [PATCH v2 14/16] perf tools: add new mem command for memory access profiling
Em Tue, Nov 06, 2012 at 04:49:26PM +0100, Stephane Eranian escreveu:
Quoted 11 lines
Quoted 8 lines · Arnaldo Carvalho de Melo
Em Mon, Nov 05, 2012 at 02:51:01PM +0100, Stephane Eranian escreveu:
tools/perf/builtin-mem.c line 50
Quoted 5 lines
tools/perf/builtin-mem.c new file +5
-0+ +if (strcmp (mem_operation,MEM_OPERATION_LOAD )) +sprintf (event,"cpu/mem-stores/pp" ); +else +sprintf (event,"cpu/mem-loads/pp" );Fails for me on a Sandy Bridge notebook:
Quoted 7 lines
That's because you need to update the microcode.
$ sudo modprobe microcode $ cat /proc/cpuinfoLine with microcode needs to say:
microcode :0x28
Here it says:
microcode : 0x25
Quoted 2 lines
update the microcode package or install directly from intel download center.
Thanks for the info, will do. And they will add "microcode hints for selected processors should give that info to the user" to my TODO list :-)
- Arnaldo
Re: [PATCH v2 14/16] perf tools: add new mem command for memory access profiling
Em Tue, Nov 06, 2012 at 01:51:19PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 13 lines
Em Tue, Nov 06, 2012 at 04:49:26PM +0100, Stephane Eranian escreveu:
Quoted 11 lines
Quoted 4 lines · Arnaldo Carvalho de Melo
Em Mon, Nov 05, 2012 at 02:51:01PM +0100, Stephane Eranian escreveu:
Quoted 1 line
+
sprintf(event, "cpu/mem-loads/pp");Fails for me on a Sandy Bridge notebook:
That's because you need to update the microcode.
$ sudo modprobe microcode $ cat /proc/cpuinfo
Quoted 6 lines
Quoted 2 lines
Line with microcode needs to say:
microcode :0x28Here it says:
microcode :
0x25
Updated it and now I have 0x28, better:
Samples: 8K of event 'cpu/mem-loads/pp', Event count (approx.): 89255
0.75% 1 665 L3 hit [.] arena_run_tree_remove 0.67% 1 602 LFB hit [.] nsSMILAnimationController::DoSample(bool) 0.63% 1 563 Local RAM hit [.] 0x00000000004620c4 0.58% 1 515 Local RAM hit [.] 0x00007f6b278aa7bc 0.54% 1 479 L2 hit [.] XPending 0.33% 1 292 Local RAM hit [.] nsSVGFEMorphologyElement::Filter(nsSVGFilterInstance*, nsTArray<
Will do more tests after lunch,
- Arnaldo
Re: [PATCH v2 14/16] perf tools: add new mem command for memory access profiling
In reply to Arnaldo Carvalho de MeloEm Tue, Nov 06, 2012 at 12:44:46PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 5 lines
[root@sandy ~]# perf record -g -a -e cpu/mem-stores/
^C[ perf record: Woken up 25 times to write data ]
[ perf record: Captured and wrote 7.419 MB perf.data (~324160 samples) ]Yay, got some numbers.
But then the results out of:
$ perf mem -t load rep --stdio
Are bogus at least on the callchains:
# ========
# captured on: Tue Nov 6 12:46:21 2012
# hostname : sandy.ghostprotocols.net
# os release : 3.7.0-rc2+
# perf version : 3.7.rc4.gfaa41f
# arch : x86_64
# nrcpus online : 8
# nrcpus avail : 8
# cpudesc : Intel(R) Core(TM) i7-2920XM CPU @ 2.50GHz
# cpuid : GenuineIntel,6,42,7
# total memory : 16220228 kB
# cmdline : /home/acme/bin/perf record -g -a -e cpu/mem-stores/
# event : name = cpu/mem-stores/, type = 4, config = 0x2cd, config1 = 0x0, config2 = 0x0, excl_usr = 0, excl_kern = 0, excl_ho
# HEADER_CPU_TOPOLOGY info available, use -I to display
# HEADER_NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: cpu = 4, software = 1, tracepoint = 2, uncore_cbox_0 = 6, uncore_cbox_1 = 7, uncore_cbox_2 = 8, uncore_cbox_3
# ========
#
# Samples: 98 of event 'cpu/mem-stores/'
# Total cost : 98
# Sort order : cost,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked
#
# Overhead Samples Cost Memory access Symbol Share
# ........ ........... ....... ........................ .............................................. ..................
#
19.39% 19 N/A [k] csd_unlock [kernel.kallsyms]
|
--- csd_unlock
|
|--6242.11%-- generic_smp_call_function_single_interrupt
| smp_call_function_single_interrupt
| call_function_single_interrupt
| cpuidle_enter
| cpuidle_enter_state
| cpuidle_idle_call
| cpu_idle
| |
| |--85.08%-- start_secondary
| |
| --14.92%-- rest_init
| start_kernel
| x86_64_start_reservations
| x86_64_start_kernel
|
|--100.00%-- smp_call_function_single_interrupt
| call_function_single_interrupt
| cpuidle_enter
| cpuidle_enter_state
| cpuidle_idle_call
| cpu_idle
| start_secondary
--97088126703734472704.00%-- [...] 5.10% 5 N/A [k] _raw_spin_lock_irqsave [kernel.kallsyms]
|
Ideas?
- Arnaldo
Re: [PATCH v2 14/16] perf tools: add new mem command for memory access profiling
Quoted 5 lines · Arnaldo Carvalho de Melo
Em Tue, Nov 06, 2012 at 12:44:46PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 4 lines
[root@sandy ~]# perf record -g -a -e cpu/mem-stores/
^C[ perf record: Woken up 25 times to write data ]
[ perf record: Captured and wrote 7.419 MB perf.data (~324160 samples) ]
Quoted 8 lines
Quoted 1 line
Yay, got some numbers.
But then the results out of:
$ perf mem -t load rep --stdioAre bogus at least on the callchains:
I think it's because we are not using the period in the hist_entry but the cost and there
is no cost for stores.
I think you should start with loads and no callchain. I am interested in your toughts on how to
fix the data symbol resolution problem in perf. In V2, I modified the kernel to at least
help perf distinguish MAP__FUNCTION from MAP__VARIABLE. But there is still something
wrong.
Quoted 61 lines
# ========
# captured on: Tue Nov 6 12:46:21 2012 # hostname : sandy.ghostprotocols.net # os release : 3.7.0-rc2+ # perf version : 3.7.rc4.gfaa41f # arch : x86_64 # nrcpus online : 8 # nrcpus avail : 8 # cpudesc : Intel(R) Core(TM) i7-2920XM CPU @ 2.50GHz # cpuid : GenuineIntel,6,42,7 # total memory : 16220228 kB # cmdline : /home/acme/bin/perf record -g -a -e cpu/mem-stores/ # event : name = cpu/mem-stores/, type = 4, config = 0x2cd, config1 = 0x0, config2 = 0x0, excl_usr = 0, excl_kern = 0, excl_ho # HEADER_CPU_TOPOLOGY info available, use -I to display # HEADER_NUMA_TOPOLOGY info available, use -I to display # pmu mappings: cpu = 4, software = 1, tracepoint = 2, uncore_cbox_0 = 6, uncore_cbox_1 = 7, uncore_cbox_2 = 8, uncore_cbox_3 # ======== # # Samples: 98 of event 'cpu/mem-stores/' # Total cost : 98 # Sort order : cost,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked # # Overhead Samples Cost Memory access Symbol Share # ........ ........... ....... ........................ .............................................. .................. # 19.39% 19 N/A [k] csd_unlock [kernel.kallsyms] | --- csd_unlock | |--6242.11%-- generic_smp_call_function_single_interrupt | smp_call_function_single_interrupt | call_function_single_interrupt | cpuidle_enter | cpuidle_enter_state | cpuidle_idle_call | cpu_idle | | | |--85.08%-- start_secondary | | | --14.92%-- rest_init | start_kernel | x86_64_start_reservations | x86_64_start_kernel | |--100.00%-- smp_call_function_single_interrupt | call_function_single_interrupt | cpuidle_enter | cpuidle_enter_state | cpuidle_idle_call | cpu_idle | start_secondary --97088126703734472704.00%-- [...]5.10% 5 N/A [k]
_raw_spin_lock_irqsave[kernel.kallsyms]
|Ideas?
- Arnaldo
Re: [PATCH v2 14/16] perf tools: add new mem command for memory access profiling
Em Tue, Nov 06, 2012 at 04:57:59PM +0100, Stephane Eranian escreveu:
Quoted 19 lines
Quoted 5 lines · Arnaldo Carvalho de Melo
Em Tue, Nov 06, 2012 at 12:44:46PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 4 lines
[root@sandy ~]# perf record -g -a -e cpu/mem-stores/
^C[ perf record: Woken up 25 times to write data ]
[ perf record: Captured and wrote 7.419 MB perf.data (~324160 samples) ]Quoted 8 lines
Quoted 1 line
Yay, got some numbers.
But then the results out of:
$ perf mem -t load rep --stdioAre bogus at least on the callchains:
I think it's because we are not using the period in the
hist_entrybut the cost and there
is no cost for stores.
Quoted 7 lines
I think you should start with loads and no callchain. I am interested in your toughts on how to
fix the data symbol resolution problem in perf. In V2, I modified the kernel to at least
help perf distinguishMAP__FUNCTIONfromMAP__VARIABLE. But there is still something
wrong.
Yeah, I saw that, now that I'm playing with this patchset I'll work on that, after lunch.
Quoted 62 lines
Quoted 62 lines
# ========
# captured on: Tue Nov 6 12:46:21 2012 # hostname : sandy.ghostprotocols.net # os release : 3.7.0-rc2+ # perf version : 3.7.rc4.gfaa41f # arch : x86_64 # nrcpus online : 8 # nrcpus avail : 8 # cpudesc : Intel(R) Core(TM) i7-2920XM CPU @ 2.50GHz # cpuid : GenuineIntel,6,42,7 # total memory : 16220228 kB # cmdline : /home/acme/bin/perf record -g -a -e cpu/mem-stores/ # event : name = cpu/mem-stores/, type = 4, config = 0x2cd, config1 = 0x0, config2 = 0x0, excl_usr = 0, excl_kern = 0, excl_ho # HEADER_CPU_TOPOLOGY info available, use -I to display # HEADER_NUMA_TOPOLOGY info available, use -I to display # pmu mappings: cpu = 4, software = 1, tracepoint = 2, uncore_cbox_0 = 6, uncore_cbox_1 = 7, uncore_cbox_2 = 8, uncore_cbox_3 # ======== # # Samples: 98 of event 'cpu/mem-stores/' # Total cost : 98 # Sort order : cost,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked # # Overhead Samples Cost Memory access Symbol Share # ........ ........... ....... ........................ .............................................. .................. # 19.39% 19 N/A [k] csd_unlock [kernel.kallsyms] | --- csd_unlock | |--6242.11%-- generic_smp_call_function_single_interrupt | smp_call_function_single_interrupt | call_function_single_interrupt | cpuidle_enter | cpuidle_enter_state | cpuidle_idle_call | cpu_idle | | | |--85.08%-- start_secondary | | | --14.92%-- rest_init | start_kernel | x86_64_start_reservations | x86_64_start_kernel | |--100.00%-- smp_call_function_single_interrupt | call_function_single_interrupt | cpuidle_enter | cpuidle_enter_state | cpuidle_idle_call | cpu_idle | start_secondary --97088126703734472704.00%-- [...]5.10% 5 N/A [k]
_raw_spin_lock_irqsave[kernel.kallsyms]
|Ideas?
- Arnaldo
PATCH v2 15/16 perf: add PERF_RECORD_MISC_MMAP_DATA to RECORD_MMAP
In reply to Stephane EranianType of mapping was lost and made it hard for a tool to distinguish code vs. data mmaps. Perf has the ability to distinguish the two.
Use a bit in the header->misc bitmask to keep track of the mmap type. If PERF_RECORD_MISC_MMAP_DATA is set then the mapping is not executable (!VM_EXEC). If not set, then the mapping is executable.
--- include/uapi/linux/perf_event.h | 1 + kernel/events/core.c | 3 +++ 2 files changed, 4 insertions(+)
include/uapi/linux/perf_event.h +1 -0
@@ -446,6 +446,7 @@ struct perf_event_mmap_page {#define PERF_RECORD_MISC_GUEST_KERNEL (4 << 0)#define PERF_RECORD_MISC_GUEST_USER (5 << 0) +#define PERF_RECORD_MISC_MMAP_DATA (1 << 13)/* * Indicates that the content of PERF_SAMPLE_IP points to * the actual instruction that triggered the event. See also
kernel/events/core.c +3 -0
@@ -4764,6 +4764,9 @@ static void perf_event_mmap_event(struct perf_mmap_event *mmap_event) mmap_event->file_name = name; mmap_event->file_size = size; +if (!(vma->vm_flags &VM_EXEC )) + mmap_event->event_id.header.misc |=PERF_RECORD_MISC_MMAP_DATA ; + mmap_event->event_id.header.size =sizeof (mmap_event->event_id) + size;rcu_read_lock ();
Signature · 1 line
1.7.9.5
PATCH v2 16/16 perf tools: detect data vs. text mappings
In reply to Stephane EranianLeverages the PERF_RECORD_MISC_MMAP_DATA bit in the RECORD_MMAP record header. When the bit is set then the mapping type is set to MAP__VARIABLE.
--- tools/perf/util/machine.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
tools/perf/util/machine.c +9 -1
@@ -192,6 +192,7 @@ int machine__process_mmap_event(struct machine *machine, union perf_event *eventu8 cpumode = event->header.misc &PERF_RECORD_MISC_CPUMODE_MASK ;struct thread *thread;struct map *map; +enum map_type type;int ret =0 ;if (dump_trace)
@@ -208,10 +209,17 @@ int machine__process_mmap_event(struct machine *machine, union perf_event *event thread =machine__findnew_thread (machine, event->mmap.pid);if (thread ==NULL ) goto out_problem; + +if (event->header.misc &PERF_RECORD_MISC_MMAP_DATA ) + type =MAP__VARIABLE ; +else + type =MAP__FUNCTION ; + map =map__new (&machine->user_dsos, event->mmap.start, event->mmap.len, event->mmap.pgoff, event->mmap.pid, event->mmap.filename, -MAP__FUNCTION ); + type); +if (map ==NULL ) goto out_problem;
Signature · 1 line
1.7.9.5
Em Mon, Nov 05, 2012 at 02:50:47PM +0100, Stephane Eranian escreveu:
Quoted 14 lines
Or if one is interested in the data view:
$ perf mem -t load rep --sort=symbol_daddr,cost # Samples: 19K of event 'cpu/mem-loads/pp' # Total cost : 1013994 # Sort order : symbol_daddr,cost # # Overhead Samples Data Symbol Cost # ........ ........... ...................... ....... # 0.10% 1 [.] 0x00007f67dffe8038 986 0.09% 1 [.] 0x00007f67df91a750 890 0.08% 1 [.] 0x00007f67e288fba8 826
Quoted 3 lines
CAVEAT: Note that the data addresses are not resolved correctly currently due to a problem in perf data symbol resolution code which I have not been able to uncover so far.
Stephane,
Those data addresses mostly are on the stack, we need reverse
resolution using DWARF location expressions to figure out what is the name of a variable that is on a particular address, etc.
Masami, have you played with this already? I mean:
[root@sandy acme]# perf mem -t load rep --stdio --sort=symbol,symbol_daddr,cost # Samples: 30 of event 'cpu/mem-loads/pp'
# Total cost : 640
# Sort order : symbol,symbol_daddr,cost
#
# Overhead Samples Symbol Data Symbol Cost
# ........ ........... ...................... ...................... .......
#
55.00% 1 [k] lookup_fast [k] 0xffff8803b7521bd4 352
5.47% 1 [k] cache_alloc_refill [k] 0xffff880407705024 35
3.44% 1 [k] cache_alloc_refill [k] 0xffff88041d8527d8 22
3.28% 1 [k] run_timer_softirq [k] 0xffff88041e2c3e90 21
2.50% 1 [k] __list_add [k] 0xffff8803b7521d68 16
2.19% 1 [.] __strcoll_l [.] 0x00007fffa8d44080 14
1.88% 1 [.] __strcoll_l [.] 0x00007fffa8d44104 12If we go to the annotation browser to see where is that lookup_fast hitting we get:
100.00 │ mov -0x34(%rbp),%eax
How to map 0xffff8803b7521bd4 to a stack variable, struct members and all?
Humm, for userspace we have PERF_SAMPLE_REGS_USER for the dwarf unwinder we need for userspace, but what about reverse mapping of kernel variables? Jiri?
- Arnaldo
Namhyung Kim
maintainerHi Arnaldo,
Quoted 17 lines · Arnaldo Carvalho de Melo
Em Mon, Nov 05, 2012 at 02:50:47PM +0100, Stephane Eranian escreveu:
[root@sandy acme]# perf mem -t load rep --stdio --sort=symbol,symbol_daddr,cost # Samples: 30 of event 'cpu/mem-loads/pp'
# Total cost : 640
# Sort order : symbol,symbol_daddr,cost
#
# Overhead Samples Symbol Data Symbol Cost# ........ ........... ...................... ...................... ....... # 55.00% 1 [k] lookup_fast [k] 0xffff8803b7521bd4 352 5.47% 1 [k] cache_alloc_refill [k] 0xffff880407705024 35 3.44% 1 [k] cache_alloc_refill [k] 0xffff88041d8527d8 22 3.28% 1 [k] run_timer_softirq [k] 0xffff88041e2c3e90 21 2.50% 1 [k] __list_add [k] 0xffff8803b7521d68 16 2.19% 1 [.] __strcoll_l [.] 0x00007fffa8d44080 14 1.88% 1 [.] __strcoll_l [.] 0x00007fffa8d44104 12
Quoted 8 lines
If we go to the annotation browser to see where is that
lookup_fasthitting we get:100.00 │ mov -0x34(%rbp),%eax
How to map
0xffff8803b7521bd4to a stack variable, struct members and all?Humm, for userspace we have
PERF_SAMPLE_REGS_USERfor the dwarf unwinder we need for userspace, but what about reverse mapping of kernel variables? Jiri?
I suspect there aren't much thing we can do on stack. One thing we can do is adding dso_daddr to sort key and seeing it's a [stack] (or [stack:tid]) or not. But not sure it can be done for kernel stacks too.
Thanks,
Namhyung
Quoted 26 lines · Namhyung Kim
Hi Arnaldo,
Quoted 23 lines · Arnaldo Carvalho de Melo
Em Mon, Nov 05, 2012 at 02:50:47PM +0100, Stephane Eranian escreveu:
[root@sandy acme]# perf mem -t load rep --stdio --sort=symbol,symbol_daddr,cost # Samples: 30 of event 'cpu/mem-loads/pp'
# Total cost : 640
# Sort order : symbol,symbol_daddr,cost
#
# Overhead Samples Symbol Data Symbol Cost# ........ ........... ...................... ...................... ....... # 55.00% 1 [k] lookup_fast [k] 0xffff8803b7521bd4 352 5.47% 1 [k] cache_alloc_refill [k] 0xffff880407705024 35 3.44% 1 [k] cache_alloc_refill [k] 0xffff88041d8527d8 22 3.28% 1 [k] run_timer_softirq [k] 0xffff88041e2c3e90 21 2.50% 1 [k] __list_add [k] 0xffff8803b7521d68 16 2.19% 1 [.] __strcoll_l [.] 0x00007fffa8d44080 14 1.88% 1 [.] __strcoll_l [.] 0x00007fffa8d44104 12If we go to the annotation browser to see where is that
lookup_fasthitting we get:100.00 │ mov -0x34(%rbp),%eax
How to map
0xffff8803b7521bd4to a stack variable, struct members and all?
Yes, you need dwarf to achieve this. But I think we should first fix the problem with global variables at the user and kernel levels and there all you need is the
data symbol table (which we load because of the -d option) and correct base+offset
calculations. For now, I am getting perf-xxxx.map for global variables.
For instance, I use the following simple test program with:
$ perf mem rec mcol 10000
I expect to see symbol aa+offset in the data symbol column and mcol in the data object column. But instance, I get raw hex and perf-xxxx.map.
I think that's what we need to fix first.
/* mcol.c */
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <inttypes.h>
typedef struct {
long real;
long img;
} elem_t;#define NB 100000ULL
static elem_t aa[NB * 2];
uint64_tmat_column(elem_t *m, size_t nr, size_t nc, elem_t *n)
{
uint64_t real = 0 , img = 0;
elem_t *p;
size_t i, j;
/* scan by columns */
for(i=0; i < nc; i++) {
for(j=0; j < nr; j++) {
real += (m+i+nc*j)->real;
img += (m+i+nc*j)->img;
}
}
return (real+img) > 0 ? 0 : 1;
}int main(int argc, char **argv)
{
size_t rows, cols;
unsigned long long nloop, nl;
elem_t number;
number.real = 1;
number.img = 5;
nloop = nl = argc > 1 ? strtoul(argv[1], NULL, 0) : 10000;
rows = NB;
cols = 2;
printf("mat[%p:%p] size=%zuMiB\n", aa, &aa[-1+NB*2], sizeof(aa) >> 20);
while(nl--) {
number.img++;
number.real += mat_column(aa, rows, cols, &number);
}
return 0;
}Quoted 19 lines · Arnaldo Carvalho de Melo
Em Mon, Nov 05, 2012 at 02:50:47PM +0100, Stephane Eranian escreveu:
Quoted 14 lines
Or if one is interested in the data view:
$ perf mem -t load rep --sort=symbol_daddr,cost # Samples: 19K of event 'cpu/mem-loads/pp' # Total cost : 1013994 # Sort order : symbol_daddr,cost # # Overhead Samples Data Symbol Cost # ........ ........... ...................... ....... # 0.10% 1 [.] 0x00007f67dffe8038 986 0.09% 1 [.] 0x00007f67df91a750 890 0.08% 1 [.] 0x00007f67e288fba8 826Quoted 3 lines
CAVEAT: Note that the data addresses are not resolved correctly currently due to a problem in perf data symbol resolution code which I have not been able to uncover so far.
Quoted 7 lines
Stephane,
Those data addresses mostly are on the stack, we need reverse
resolution using DWARF location expressions to figure out what is the name of a variable that is on a particular address, etc.Masami, have you played with this already? I mean:
No, but it looks interesting. I'll try :)
Quoted 17 lines
[root@sandy acme]# perf mem -t load rep --stdio --sort=symbol,symbol_daddr,cost # Samples: 30 of event 'cpu/mem-loads/pp'
# Total cost : 640
# Sort order : symbol,symbol_daddr,cost
#
# Overhead Samples Symbol Data Symbol Cost# ........ ........... ...................... ...................... ....... # 55.00% 1 [k] lookup_fast [k] 0xffff8803b7521bd4 352 5.47% 1 [k] cache_alloc_refill [k] 0xffff880407705024 35 3.44% 1 [k] cache_alloc_refill [k] 0xffff88041d8527d8 22 3.28% 1 [k] run_timer_softirq [k] 0xffff88041e2c3e90 21 2.50% 1 [k] __list_add [k] 0xffff8803b7521d68 16 2.19% 1 [.] __strcoll_l [.] 0x00007fffa8d44080 14 1.88% 1 [.] __strcoll_l [.] 0x00007fffa8d44104 12
Quoted 5 lines
If we go to the annotation browser to see where is that
lookup_fasthitting we get:100.00 │ mov -0x34(%rbp),%eax
How to map
0xffff8803b7521bd4to a stack variable, struct members and all?
If perf stores %rbp value, we can do forward searching from local variables in this scope block. In some cases, the memory is dereferenced by another pointer. In that case, it is hard to do that (perhaps, we need to disassemble it and reverse execution). But in most case of the memory address on a stack, it will work, I think.
Thank you,
Quoted 11 lines
Humm, for userspace we have
PERF_SAMPLE_REGS_USERfor the dwarf unwinder we need for userspace, but what about reverse mapping of kernel variables? Jiri?- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 4 lines
Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: [email protected]
Quoted 51 lines · Masami Hiramatsu
Quoted 19 lines · Arnaldo Carvalho de Melo
Em Mon, Nov 05, 2012 at 02:50:47PM +0100, Stephane Eranian escreveu:
Quoted 14 lines
Or if one is interested in the data view:
$ perf mem -t load rep --sort=symbol_daddr,cost # Samples: 19K of event 'cpu/mem-loads/pp' # Total cost : 1013994 # Sort order : symbol_daddr,cost # # Overhead Samples Data Symbol Cost # ........ ........... ...................... ....... # 0.10% 1 [.] 0x00007f67dffe8038 986 0.09% 1 [.] 0x00007f67df91a750 890 0.08% 1 [.] 0x00007f67e288fba8 826Quoted 3 lines
CAVEAT: Note that the data addresses are not resolved correctly currently due to a problem in perf data symbol resolution code which I have not been able to uncover so far.
Quoted 7 lines
Stephane,
Those data addresses mostly are on the stack, we need reverse
resolution using DWARF location expressions to figure out what is the name of a variable that is on a particular address, etc.Masami, have you played with this already? I mean:
No, but it looks interesting. I'll try :)
Quoted 21 lines
[root@sandy acme]# perf mem -t load rep --stdio --sort=symbol,symbol_daddr,cost # Samples: 30 of event 'cpu/mem-loads/pp'
# Total cost : 640
# Sort order : symbol,symbol_daddr,cost
#
# Overhead Samples Symbol Data Symbol Cost# ........ ........... ...................... ...................... ....... # 55.00% 1 [k] lookup_fast [k] 0xffff8803b7521bd4 352 5.47% 1 [k] cache_alloc_refill [k] 0xffff880407705024 35 3.44% 1 [k] cache_alloc_refill [k] 0xffff88041d8527d8 22 3.28% 1 [k] run_timer_softirq [k] 0xffff88041e2c3e90 21 2.50% 1 [k] __list_add [k] 0xffff8803b7521d68 16 2.19% 1 [.] __strcoll_l [.] 0x00007fffa8d44080 14 1.88% 1 [.] __strcoll_l [.] 0x00007fffa8d44104 12If we go to the annotation browser to see where is that
lookup_fasthitting we get:100.00 │ mov -0x34(%rbp),%eax
Quoted 8 lines
Quoted 1 line
How to map
0xffff8803b7521bd4to a stack variable, struct members and all?If perf stores %rbp value, we can do forward searching from local variables in this scope block. In some cases, the memory is dereferenced by another pointer. In that case, it is hard to do that (perhaps, we need to disassemble it and reverse execution). But in most case of the memory address on a stack, it will work, I think.
PEBS-LL does store rbp but it is not yet exposed. That will be in a follow-up patch.
Quoted 22 lines
Thank you,
Quoted 11 lines
Humm, for userspace we have
PERF_SAMPLE_REGS_USERfor the dwarf unwinder we need for userspace, but what about reverse mapping of kernel variables? Jiri?- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory
E-mail: [email protected]