- 23 Jun, 2013 2 commits
-
-
Dave Hansen authored
This patch keeps track of how long perf's NMI handler is taking, and also calculates how many samples perf can take a second. If the sample length times the expected max number of samples exceeds a configurable threshold, it drops the sample rate. This way, we don't have a runaway sampling process eating up the CPU. This patch can tend to drop the sample rate down to level where perf doesn't work very well. *BUT* the alternative is that my system hangs because it spends all of its time handling NMIs. I'll take a busted performance tool over an entire system that's busted and undebuggable any day. BTW, my suspicion is that there's still an underlying bug here. Using the HPET instead of the TSC is definitely a contributing factor, but I suspect there are some other things going on. But, I can't go dig down on a bug like that with my machine hanging all the time. Signed-off-by:
Dave Hansen <dave.hansen@linux.intel.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: paulus@samba.org Cc: acme@ghostprotocols.net Cc: Dave Hansen <dave@sr71.net> [ Prettified it a bit. ] Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Dave Hansen authored
I have a system which is causing all kinds of problems. It has 8 NUMA nodes, and lots of cores that can fight over cachelines. If things are not working _perfectly_, then NMIs can take longer than expected. If we get too many of them backed up to each other, we can easily end up in a situation where we are doing nothing *but* running NMIs. The biggest problem, though, is that this happens _silently_. You might be lucky to get an hrtimer warning, but most of the time system simply hangs. This patch should at least give us some warning before we fall off the cliff. the warnings look like this: nmi_handle: perf_event_nmi_handler() took: 26095071 ns The message is triggered whenever we notice the longest NMI we've seen to date. You can always view and reset this value via the debugfs interface if you like. Signed-off-by:
-
- 20 Jun, 2013 9 commits
-
-
Oleg Nesterov authored
This patch simply moves all per-cpu variables into the new single per-cpu "struct bp_cpuinfo". To me this looks more logical and clean, but this can also simplify the further potential changes. In particular, I do not think this memory should be per-cpu, it is never used "locally". After this change it is trivial to turn it into, say, bootmem[nr_cpu_ids]. Reported-by:
Vince Weaver <vincent.weaver@maine.edu> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Frederic Weisbecker <fweisbec@gmail.com> Link: http://lkml.kernel.org/r/20130620155020.GA6350@redhat.comSigned-off-by:
-
Oleg Nesterov authored
1. register_wide_hw_breakpoint() can use unregister_ if failure, no need to duplicate the code. 2. "struct perf_event **pevent" adds the unnecesary lever of indirection and complication, use per_cpu(*cpu_events, cpu). Reported-by:
-
Oleg Nesterov authored
Add the trivial helper which simply returns cpumask_of() or cpu_possible_mask depending on bp->cpu. Change fetch_bp_busy_slots() and toggle_bp_slot() to always do for_each_cpu(cpumask_of_bp) to simplify the code and avoid the code duplication. Reported-by:
-
Oleg Nesterov authored
Change toggle_bp_slot() to make "weight" negative if !enable. This way we can always use "+ weight" without additional "if (enable)" check and toggle_bp_task_slot() no longer needs this arg. Reported-by:
-
Oleg Nesterov authored
The enable/disable logic in toggle_bp_slot() is not symmetrical and imho very confusing. "old_count" in toggle_bp_task_slot() is actually new_count because this bp was already removed from the list. Change toggle_bp_slot() to always call list_add/list_del after toggle_bp_task_slot(). This way old_idx is task_bp_pinned() and this entry should be decremented, new_idx is +/-weight and we need to increment this element. The code/logic looks obvious. Reported-by:
-
Ingo Molnar authored
Merge in two hw_breakpoint fixes, before applying another 5. Signed-off-by: -
Oleg Nesterov authored
fetch_bp_busy_slots() and toggle_bp_slot() use for_each_online_cpu(), this is obviously wrong wrt cpu_up() or cpu_down(), we can over/under account the per-cpu numbers. For example: # echo 0 >> /sys/devices/system/cpu/cpu1/online # perf record -e mem:0x10 -p 1 & # echo 1 >> /sys/devices/system/cpu/cpu1/online # perf record -e mem:0x10,mem:0x10,mem:0x10,mem:0x10 -C1 -a & # taskset -p 0x2 1 triggers the same WARN_ONCE("Can't find any breakpoint slot") in arch_install_hw_breakpoint(). Reported-by: -
Oleg Nesterov authored
trinity fuzzer triggered WARN_ONCE("Can't find any breakpoint slot") in arch_install_hw_breakpoint() but the problem is not arch-specific. The problem is, task_bp_pinned(cpu) checks "cpu == iter->cpu" but this doesn't account the "all cpus" events with iter->cpu < 0. This means that, say, register_user_hw_breakpoint(tsk) can happily create the arbitrary number > HBP_NUM of breakpoints which can not be activated. toggle_bp_task_slot() is equally wrong by the same reason and nr_task_bp_pinned[] can have negative entries. Simple test: # perl -e 'sleep 1 while 1' & # perf record -e mem:0x10,mem:0x10,mem:0x10,mem:0x10,mem:0x10 -p `pidof perl` Before this patch this triggers the same problem/WARN_ON(), after the patch it correctly fails with -ENOSPC. Reported-by: -
Masami Hiramatsu authored
Fix arch_prepare_kprobe() to handle failures in copy instruction correctly. This fix is related to the previous fix: 8101376d which made __copy_instruction return an error result if failed, but caller site was not updated to handle it. Thus, this is the other half of the bugfix. This fix is also related to the following bug-report: https://bugzilla.redhat.com/show_bug.cgi?id=910649Signed-off-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Acked-by:
Steven Rostedt <rostedt@goodmis.org> Tested-by:
Jonathan Lebon <jlebon@redhat.com> Cc: Frank Ch. Eigler <fche@redhat.com> Cc: systemtap@sourceware.org Cc: yrl.pp-manager.tt@hitachi.com Link: http://lkml.kernel.org/r/20130605031216.15285.2001.stgit@mhiramat-M0-7522Signed-off-by:
-
- 19 Jun, 2013 16 commits
-
-
Andi Kleen authored
mem-loads is basically the same as Sandy Bridge, but we use a separate string for changes later. Haswell doesn't support the full precise store mode, so we emulate it using the "DataLA" facility. This allows to do everything, but for data sources we can only detect L1 hit or not. There is no explicit enable bit anymore, so we have to tie it to a perf internal only flag. The address is supported for all memory related PEBS events with DataLA. Instead of only logging for the load and store events we allow logging it for all (it will be simply 0 if the current event does not support it) Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Andi Kleen <ak@linux.jf.intel.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Link: http://lkml.kernel.org/r/1371515812-9646-7-git-send-email-andi@firstfloor.orgSigned-off-by:
-
Andi Kleen authored
Haswell has two additional LBR from flags for TSX: in_tx and abort_tx, implemented as a new "v4" version of the LBR format. Handle those in and adjust the sign extension code to still correctly extend. The flags are exported similarly in the LBR record to the existing misprediction flag Signed-off-by:
-
Andi Kleen authored
This avoids some problems with spurious PMIs on Haswell. Haswell seems to behave more like P4 in this regard. Do the same thing as the P4 perf handler by unmasking the NMI only at the end. Shouldn't make any difference for earlier family 6 cores. (Tested on Haswell, IvyBridge, Westmere, Saltwell (Atom).) Signed-off-by:
-
Andi Kleen authored
Add simple PEBS support for Haswell. The constraints are similar to SandyBridge with a few new events. Reviewed-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
-
Andi Kleen authored
Similar to SandyBridge, but has a few new events and two new counter bits. There are some new counter flags that need to be prevented from being set on fixed counters, and allowed to be set for generic counters. Also we add support for the counter 2 constraint to handle all raw events. (Contains fixes from Stephane Eranian.) Reviewed-by:
-
Andi Kleen authored
Add support for the Haswell extended (fmt2) PEBS format. It has a superset of the nhm (fmt1) PEBS fields, but has a longer record so we need to adjust the code paths. The main advantage is the new "EventingRip" support which directly gives the instruction, not off-by-one instruction. So with precise == 2 we use that directly and don't try to use LBRs and walking basic blocks. This lowers the overhead of using precise significantly. Some other features are added in later patches. Reviewed-by:
-
Yan, Zheng authored
Signed-off-by:
Yan, Zheng <zheng.z.yan@intel.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1370421025-10986-1-git-send-email-zheng.z.yan@intel.comSigned-off-by:
-
Suravee Suthikulpanit authored
Implement a perf PMU to handle IOMMU performance counters and events. The PMU only supports counting mode (e.g. perf stat). Since the counters are shared across all cores, the PMU is implemented as "system-wide" mode. To invoke the AMD IOMMU PMU, issue a perf tool command such as: ./perf stat -a -e amd_iommu/<events>/ <command> or: ./perf stat -a -e amd_iommu/config=<config-data>,config1=<config1-data>/ <command> For example: ./perf stat -a -e amd_iommu/mem_trans_total/ <command> The resulting count will be how many IOMMU total peripheral memory operations were performed during the command execution window. Signed-off-by:
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Signed-off-by:
-
Steven L Kinney authored
Add functionality to check the availability of the AMD IOMMU Performance Counters and export this functionality to other core drivers, such as in this case, a perf AMD IOMMU PMU. This feature is not bound to any specific AMD family/model other than the presence of the IOMMU with P-C enabled. The AMD IOMMU P-C support static counting only at this time. Signed-off-by:
Steven Kinney <steven.kinney@amd.com> Signed-off-by:
-
Dave Hansen authored
intel_pmu_handle_irq() has a warning in it if it does too many loops. It is a WARN_ONCE(), but the perf_event_print_debug() call beneath it is unconditional. For the first warning, you get a nice backtrace and message, but subsequent ones just dump the PMU state with no leading messages. I doubt this is what was intended. This patch will only print the PMU state when paired with the WARN_ON() text. It effectively open-codes WARN_ONCE()'s one-time-only logic. My suspicion is that the code really just wants to make sure we do not sit in the loop and spit out a warning for every loop iteration after the 100th. From what I've seen, this is very unlikely to happen since we also clear the PMU state. After this patch, instead of seeing the PMU state dumped each time, you will just see: [57494.894540] perf_event_intel: clearing PMU state on CPU#129 [57579.539668] perf_event_intel: clearing PMU state on CPU#10 [57587.137762] perf_event_intel: clearing PMU state on CPU#134 [57623.039912] perf_event_intel: clearing PMU state on CPU#114 [57644.559943] perf_event_intel: clearing PMU state on CPU#118 ... Signed-off-by:
-
Andrew Hunter authored
x86_schedule_events() caches event constraints on the stack during scheduling. Given the number of possible events, this is 512 bytes of stack; since it can be invoked under schedule() under god-knows-what, this is causing stack blowouts. Trade some space usage for stack safety: add a place to cache the constraint pointer to struct perf_event. For 8 bytes per event (1% of its size) we can save the giant stack frame. This shouldn't change any aspect of scheduling whatsoever and while in theory the locality's a tiny bit worse, I doubt we'll see any performance impact either. Tested: `perf stat whatever` does not blow up and produces results that aren't hugely obviously wrong. I'm not sure how to run particularly good tests of perf code, but this should not produce any functional change whatsoever. Signed-off-by:
Andrew Hunter <ahh@google.com> Reviewed-by:
-
Mischa Jonker authored
This allows us to use pdev->name for registering a PMU device. IMO the name is not supposed to be changed anyway. Signed-off-by:
Mischa Jonker <mjonker@synopsys.com> Signed-off-by:
-
Stephane Eranian authored
Commit 2b923c8f perf/x86: Check branch sampling priv level in generic code was missing the check for the hypervisor (HV) priv level, so add it back. With this patch, we get the following correct behavior: # echo 2 >/proc/sys/kernel/perf_event_paranoid $ perf record -j any,k noploop 1 Error: You may not have permission to collect stats. Consider tweaking /proc/sys/kernel/perf_event_paranoid: -1 - Not paranoid at all 0 - Disallow raw tracepoint access for unpriv 1 - Disallow cpu events for unpriv 2 - Disallow kernel profiling for unpriv $ perf record -j any,hv noploop 1 Error: You may not have permission to collect stats. Consider tweaking /proc/sys/kernel/perf_event_paranoid: -1 - Not paranoid at all 0 - Disallow raw tracepoint access for unpriv 1 - Disallow cpu events for unpriv 2 - Disallow kernel profiling for unpriv Signed-off-by:
Petr Matousek <pmatouse@redhat.com> Signed-off-by:
-
Ingo Molnar authored
Merge in the latest fixes, to avoid conflicts with ongoing work. Signed-off-by: -
Stephane Eranian authored
This patch fixes broken support of PEBS-LL on SNB-EP/IVB-EP. For some reason, the LDLAT extra reg definition for snb_ep showed up as duplicate in the snb table. This patch moves the definition of LDLAT back into the snb_ep table. Thanks to Don Zickus for tracking this one down. Signed-off-by:
-
Peter Zijlstra authored
Vince's fuzzer once again found holes. This time it spotted a leak in the locked page accounting. When an event had redirected output and its close() was the last reference to the buffer we didn't have a vm context to undo accounting. Change the code to destroy the buffer on the last munmap() and detach all redirected events at that time. This provides us the right context to undo the vm accounting. Reported-and-tested-by:
-
- 31 May, 2013 1 commit
-
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core perf/core improvements and fixes: * Reset SIGTERM handler in workload child process, fix from David Ahern. * Handle death by SIGTERM in 'perf record', fix from David Ahern. * Fix printing of perf_event_paranoid message, from David Ahern. * Handle realloc failures in 'perf kvm', from David Ahern. * Fix divide by 0 in variance, from David Ahern. * Save parent pid in thread struct, from David Ahern. * Handle JITed code in shared memory, from Andi Kleen. * Makefile reorganization, prep work for Kconfig patches, from Jiri Olsa. * Fixes for 'perf diff', from Jiri Olsa. * Add automated make test suite, from Jiri Olsa. * 'perf tests' fixes from Jiri Olsa. * Remove some unused struct members, from Jiri Olsa. * Add missing liblk.a dependency for python/perf.so, fix from Jiri Olsa. * Respect CROSS_COMPILE in liblk.a, from Rabin Vincent. * Expand definition of sysfs format attribute, from Michael Ellerman. * No need to do locking when adding hists in perf report, only 'top' needs that, from Namhyung Kim. * Sorting improvements, from Namhyung Kim. * Fix alignment of symbol column in in the hists browser (top, report) when -v is given, from NAmhyung Kim. * Add --percent-limit option to 'top' and 'report', from Namhyung Kim. * Fix 'perf top' -E option behavior, from Namhyung Kim. * Fix bug in isupper() and islower(), from Sukadev Bhattiprolu. * Fix compile errors in bp_signal 'perf test', from Sukadev Bhattiprolu. * Make Power7 CPI stack events available in sysfs, from Sukadev Bhattiprolu. Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
- 30 May, 2013 9 commits
-
-
Jiri Olsa authored
Adding missing liblk.a dependency for python/perf.so. Signed-off-by:
Jiri Olsa <jolsa@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1369398928-9809-26-git-send-email-jolsa@redhat.comSigned-off-by:
-
Jiri Olsa authored
No need to use '?=' assignment for STRIP variable, the standard '=' does the same job without creating confusion. Suggested-by:
Namhyung Kim <namhyung@kernel.org> Signed-off-by:
-
Jiri Olsa authored
Replacing multiple line assignment with multiple statements. Suggested-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Jiri Olsa authored
Replacing tabs with spaces for all non-commands statements in 'Makefile' and 'config/Makefile' files. Suggested-by:
-
Jiri Olsa authored
Adding NO_BIONIC variable to confiure bionic setup Signed-off-by:
-
Jiri Olsa authored
Switching to full path C include directories, to make the includes clear. Plus little include cleanup. Signed-off-by:
-
Jiri Olsa authored
Merging all *LDFLAGS* make variable into LDFLAGS to eliminate all special *LDFLAGS* variables and make the setup clear. Signed-off-by:
-
Jiri Olsa authored
Merging all *CFLAGS* make variable into CFLAGS to eliminate all special *_CFLAGS_* variables and make the setup clear. Signed-off-by:
-
David Ahern authored
Jiri reported hanging perf tests on latest acme's perf/core and bisected it to 87f303a9f: [jolsa@krava2 perf]$ cat /proc/sys/kernel/perf_event_paranoid 1 [jolsa@krava2 perf]$ ./perf record -C 0 kill Error: You may not have permission to collect %sstats. Consider tweaking /proc/sys/kernel/perf_event_paranoid: -1 - Not paranoid at all 0 - Disallow raw tracepoint access for unpriv 1 - Disallow cpu events for unpriv 2 - Disallow kernel profiling for unpriv Need to let default handling kickin for workload process. Reported-by:
David Ahern <dsahern@gmail.com> Acked-by:
-
- 29 May, 2013 3 commits
-
-
Michael Ellerman authored
Make it explicit that the format attributes may define overlapping bit ranges. Unfortunately this was left unspecified originally, and all the examples show non-overlapping ranges. I don't believe this is an ABI change, as we are defining something that was previously undefined, but others may disagree. The POWER8 PMU would like to define overlapping ranges, as bit ranges in the event code have different meanings for certain events. It will also allow us to define an overarching "event" field, that encompasses all others. As far as I can see perf is comfortable with this change, however I am not sure if there are any other users of the interface. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Acked-by:
-
Sukadev Bhattiprolu authored
Following patch added several Power7 events into /sys/devices/cpu/events. Document those events in the testing ABI. https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-April/105167.htmlSigned-off-by:
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: linuxppc-dev@ozlabs.org Link: http://lkml.kernel.org/r/20130406170623.GA900@us.ibm.comSigned-off-by:
-
Sukadev Bhattiprolu authored
A set of Power7 events are often used for Cycles Per Instruction (CPI) stack analysis. Make these events available in sysfs (/sys/devices/cpu/events/) so they can be identified using their symbolic names: perf stat -e 'cpu/PM_CMPLU_STALL_DCACHE_MISS/' /bin/ls Signed-off-by:
Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: linuxppc-dev@ozlabs.org Link: http://lkml.kernel.org/r/20130406164803.GA408@us.ibm.comSigned-off-by:
-
