- 18 May, 2012 1 commit
-
-
Jiri Olsa authored
Introducing type_val and type_term for term instead of a single type value. Currently the term type marked out the value type as well. With this change we can have future string term values being specified by user and translated into proper number along the processing. Signed-off-by:
Jiri Olsa <jolsa@redhat.com> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Robert Richter <robert.richter@amd.com> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1335371102-11358-2-git-send-email-jolsa@redhat.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
- 17 May, 2012 2 commits
-
-
Jiri Olsa authored
The callchain address is stored as u64. Current code uses following format string to display callchain address: "%p\n", (void *)(long)chain->ip This way we lose upper 32 bits if we report 64 bit addresses in 32 bit environment. Fixing this to always display whole 64 bits. Note, running following to test perf endianity handling: test 1) - origin system: # perf record -a -- sleep 10 (any perf record will do) # perf report > report.origin # perf archive perf.data - copy the perf.data, report.origin and perf.data.tar.bz2 to a target system and run: # tar xjvf perf.data.tar.bz2 -C ~/.debug # perf report > report.target # diff -u report.origin report.target - the diff should produce no output (besides some white space stuff and possibly different date/TZ output) test 2) - origin system: # perf record -ag -fo /tmp/perf.data -- sleep 1 - mount origin system root to the target system on /mnt/origin - target system: # perf script --symfs /mnt/origin -I -i /mnt/origin/tmp/perf.data \ --kallsyms /mnt/origin/proc/kallsyms - complete perf.data header is displayed Signed-off-by: -
Namhyung Kim authored
If perf doesn't mmap on event (like perf stat), it should not create per-task-per-cpu events. So just use a dummy cpu map to create a per-task event for this case. Signed-off-by:
Namhyung Kim <namhyung.kim@lge.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1337161549-9870-3-git-send-email-namhyung.kim@lge.com [ committer note: renamed .need_mmap to .uses_mmap ] Signed-off-by:
-
- 16 May, 2012 2 commits
-
-
Namhyung Kim authored
The commit 55261f46 ("perf evlist: Fix creation of cpu map") changed to create a per-task event when no cpu target is specified. However it caused a problem since perf-task do not allow event inheritance due to scalability issues so that the result will contain samples only from parent, not from its children. So we should use perf-task-per-cpu events anyway to get the right result. Revert it. Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Analysed-by:
Ingo Molnar <mingo@kernel.org> Acked-and-tested-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Namhyung Kim authored
Rename perf_target__no_{cpu,task} to perf_target__has_{cpu,task} because it's more intuitive and easy to parse (for human beings) when used with negation. The names are came out from David Ahern. It is intended to be a mechanical substitution without any functional change. The perf_target__none remains unchanged since I couldn't find a right name and it is hardly used with negation. Signed-off-by:David Ahern <dsahern@gmail.com> Suggested-by:
-
- 14 May, 2012 2 commits
-
-
Robert Richter authored
Fixing i386 allnoconfig built errors: arch/x86/built-in.o: In function `amd_pmu_hw_config': perf_event_amd.c:(.text+0xc3e1): undefined reference to `get_ibs_caps' Reported-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Robert Richter <robert.richter@amd.com> Signed-off-by:
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Arjan & Linus Annotation Edition - Fix indirect calls beautifier, reported by Linus. - Use the objdump comments to nuke specificities about how access to a well know variable is encoded, suggested by Linus. - Show the number of places that jump to a target, requested by Arjan. Signed-off-by:
-
- 12 May, 2012 5 commits
-
-
Arnaldo Carvalho de Melo authored
Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-1txmtzf71eqie5xcukbfxors@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Just press 'J' and see how many places jump to jump targets. The hottest jump target appears in red, targets with more than one source have a different color than single source jump targets. Suggested-by:
Arjan van de Ven <arjan@infradead.org> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-7452y0dmc02a20ooins7rn79@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Instead of simply marking an offset as a jump target. So that we can implement a new feature: showing "jumpy" targets, I.e. addresses that lots of places jump to. Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-vc7b0u5yxgrubig0q61ayhxf@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
So that we don't special case disasm_line__free, allowing each instruction class to provide an specialized destructor, like is needed for 'lock'. Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-xxw4vs5n077tf35jsvjzylhb@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
It just chops off the 'lock' and uses the ins__find, etc machinery to call instruction specific parsers/beautifiers. Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-4913ba2dzakz5rivgumosqbh@git.kernel.orgSigned-off-by:
-
- 11 May, 2012 4 commits
-
-
Arnaldo Carvalho de Melo authored
Starting with inc, incl, dec, decl. Requested-by:
-
Arnaldo Carvalho de Melo authored
This: mov 0x95bbb6(%rip),%ecx # ffffffff81ae8d04 <d_hash_shift> Becomes: mov d_hash_shift,%ecx Ditto for many more instructions that take two operands. Requested-by: -
Arnaldo Carvalho de Melo authored
callq *0x10(%rax) was being rendered in simplified mode as: callq *10 I.e. hexa, but without the 0x and omitting the register. In such cases just use the raw form. Reported-by:
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Fixes and improvements for perf/core: - perf_target: abstraction for --uid, --pid, --tid, --cpu, --all-cpus handling, eliminating code duplicated in the tools, having constraints that apply to all of them, from Namhyung Kim - Fixes for handling fallback to cpu-clock on PPC, from David Ahern - Fix for processing events with unknown size, from Jiri Olsa - Compilation fix on 32-bit, from Jiri Olsa Signed-off-by:
-
- 10 May, 2012 1 commit
-
-
Arnaldo Carvalho de Melo authored
That is what is used in vi and mutt, and as well on the 'annotate' browser. Eventually we can have keymappings to make people used to other key associations more confortable. Suggested-by:
-
- 09 May, 2012 23 commits
-
-
Ingo Molnar authored
Merge branch 'tip/perf/core' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace into perf/core
-
David Ahern authored
Additional toggles have pushed the help line out of view on a modestly sized terminal (120 columns wide). Shorten it to just reminders. Signed-off-by:
-
David Ahern authored
perf-record defaults to the H/W cycles event and if it is not supported falls back to cpu-clock. Reset the event name as well. Signed-off-by:
-
David Ahern authored
The 'perf top' command falls back to cpu-clock if the H/W cycles event is not supported, but the event name is not updated leading to a misleading header: PerfTop: 8 irqs/sec kernel:75.0% exact: 0.0% [1000Hz cycles], ... Update the event name when the event type is changed so that the header displays correctly: PerfTop: 794 irqs/sec kernel:100.0% exact: 0.0% [1000Hz cpu-clock], ... Signed-off-by:
-
David Ahern authored
perf stat on PPC currently fails to run: $ perf stat -- sleep 1 Error: open_counter returned with 6 (No such device or address). /bin/dmesg may provide additional information. Fatal: Not all events could be opened. The problem is that until 2.6.37 (behavior changed with commit b0a873eb) perf on PPC returns ENXIO when hw_perf_event_init() fails. With this patch we get the expected behavior: $ perf stat -v -- sleep 1 cycles event is not supported by the kernel. stalled-cycles-frontend event is not supported by the kernel. stalled-cycles-backend event is not supported by the kernel. instructions event is not supported by the kernel. branches event is not supported by the kernel. branch-misses event is not supported by the kernel. ... Signed-off-by:
-
David Ahern authored
perf-record on PPC is not falling back to cpu-clock: $ perf record -ag -fo /tmp/perf.data -- sleep 1 Error: sys_perf_event_open() syscall returned with 6 (No such device or address). /bin/dmesg may provide additional information. Fatal: No CONFIG_PERF_EVENTS=y kernel support configured? The problem is that until 2.6.37 (behavior changed with commit b0a873eb) perf on PPC returns ENXIO when hw_perf_event_init() fails. With this patch we get the expected behavior: $ perf record -ag -fo /tmp/perf.data -v -- sleep 1 Old kernel, cannot exclude guest or host samples. The cycles event is not supported, trying to fall back to cpu-clock-ticks [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.151 MB /tmp/perf.data (~6592 samples) ] Signed-off-by:
-
Jiri Olsa authored
Using PRIu64 for printing out u64 nr_events to fix compilation for x86 32 bits. Cc: Arun Sharma <asharma@fb.com> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Frank C. Eigler <fche@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Robert Richter <robert.richter@amd.com> Cc: Stephane Eranian <eranian@google.com> Cc: Tom Zanussi <tzanussi@gmail.com> Cc: Ulrich Drepper <drepper@gmail.com> Link: http://lkml.kernel.org/r/1335958638-5160-7-git-send-email-jolsa@redhat.comSigned-off-by:
-
Peter Zijlstra authored
We can easily use a single callback for both sched-in and sched-out. This reduces the code footprint in the scheduler path as well as removes the PMU black spot otherwise present between the out and in callback. Signed-off-by:
-
Robert Richter authored
The value of IbsOpCurCnt rolls over when it reaches IbsOpMaxCnt. Thus, it is reset to zero by hardware. To get the correct count we need to add the max count to it in case we received an ibs sample (valid bit set). Signed-off-by:
-
Robert Richter authored
After disabling IBS there could be still incomming NMIs with samples that even have the valid bit cleared. Mark all this NMIs as handled to avoid spurious interrupt messages. Signed-off-by:
-
Robert Richter authored
When disabling ibs there might be the case where hardware continuously generates interrupts. This is described in erratum #420 (Instruction- Based Sampling Engine May Generate Interrupt that Cannot Be Cleared). To avoid this we must clear the counter mask first and then clear the enable bit. This patch implements this. See Revision Guide for AMD Family 10h Processors, Publication #41322. Note: We now keep track of the last read ibs config value which is then used to disable ibs. To update the config value we pass now a pointer to the functions reading it. Signed-off-by:
-
Robert Richter authored
If the last hw period is too short we might hit the irq handler which biases the results. Thus try to have a max last period that triggers the sw overflow. Signed-off-by:
-
Robert Richter authored
There are cases where the remaining period is smaller than the minimal possible value. In this case the counter is restarted with the minimal period. This is of no use as the interrupt handler will trigger immediately again and most likely hits itself. This biases the results. So, if the remaining period is within the min range, we better do not restart the counter and instead trigger the overflow. Signed-off-by:
-
Robert Richter authored
Simple patch that just renames some variables for better understanding. Signed-off-by:
-
Robert Richter authored
This patch adds support for precise event sampling with IBS. There are two counting modes to count either cycles or micro-ops. If the corresponding performance counter events (hw events) are setup with the precise flag set, the request is redirected to the ibs pmu: perf record -a -e cpu-cycles:p ... # use ibs op counting cycle count perf record -a -e r076:p ... # same as -e cpu-cycles:p perf record -a -e r0C1:p ... # use ibs op counting micro-ops Each ibs sample contains a linear address that points to the instruction that was causing the sample to trigger. With ibs we have skid 0. Thus, ibs supports precise levels 1 and 2. Samples are marked with the PERF_EFLAGS_EXACT flag set. In rare cases the rip is invalid when IBS was not able to record the rip correctly. Then the PERF_EFLAGS_EXACT flag is cleared and the rip is taken from pt_regs. V2: * don't drop samples in precise level 2 if rip is invalid, instead support the PERF_EFLAGS_EXACT flag Signed-off-by:
-
Robert Richter authored
Each IBS sample contains a linear address of the instruction that caused the sample to trigger. This address is more precise than the rip that was taken from the interrupt handler's stack. Update the rip with that address. We use this in the next patch to implement precise-event sampling on AMD systems using IBS. Signed-off-by:
-
Robert Richter authored
Fixing profiling at a fixed frequency, in this case the freq value and sample period was setup incorrectly. Since sampling periods are adjusted we also allow periods that have lower 4 bits set. Another fix is the setup of the hw counter: If we modify hwc->sample_period, we also need to update hwc->last_period and hwc->period_left. Signed-off-by:
-
Robert Richter authored
Allow enabling ibs op micro-ops counting mode. Signed-off-by:
-
Robert Richter authored
We always need to pass the last sample period to perf_sample_data_init(), otherwise the event distribution will be wrong. Thus, modifiyng the function interface with the required period as argument. So basically a pattern like this: perf_sample_data_init(&data, ~0ULL); data.period = event->hw.last_period; will now be like that: perf_sample_data_init(&data, ~0ULL, event->hw.last_period); Avoids unininitialized data.period and simplifies code. Signed-off-by: -
Robert Richter authored
The last sw period was not correctly updated on overflow and thus led to wrong distribution of events. We always need to properly initialize data.period in struct perf_sample_data. Signed-off-by:
-
Ingo Molnar authored
-
Steven Rostedt authored
The ftrace_disable_cpu() and ftrace_enable_cpu() functions were needed back before the ring buffer was lockless. Now that the ring buffer is lockless (and has been for some time), these functions serve no purpose, and unnecessarily slow down operations of the tracer. Signed-off-by:Steven Rostedt <rostedt@goodmis.org>
-
Jiri Olsa authored
It's appropriate to use __seq_open_private interface to open some of trace seq files, because it covers all steps we are duplicating in tracing code - zallocating the iterator and setting it as seq_file's private. Using this for following files: trace available_filter_functions enabled_functions Link: http://lkml.kernel.org/r/1335342219-2782-5-git-send-email-jolsa@redhat.comSigned-off-by:
-
