Dave Hansen 14c63f17b1 perf: Drop sample rate when sampling is too slow ... 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>		2013-06-23 11:52:57 +02:00
..
callchain.c
core.c	perf: Drop sample rate when sampling is too slow	2013-06-23 11:52:57 +02:00
hw_breakpoint.c	hw_breakpoint: Introduce "struct bp_cpuinfo"	2013-06-20 17:58:57 +02:00
internal.h	perf: Fix mmap() accounting hole	2013-06-19 12:44:13 +02:00
Makefile
ring_buffer.c	perf: Fix vmalloc ring buffer pages handling	2013-05-01 12:34:46 +02:00
uprobes.c	uretprobes: Remove -ENOSYS as return probes implemented	2013-04-13 15:31:58 +02:00