perf: Drop sample rate when sampling is too slow
authorDave Hansen <dave.hansen@linux.intel.com>
Fri, 21 Jun 2013 15:51:36 +0000 (08:51 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 11 Jun 2014 19:03:26 +0000 (12:03 -0700)
commit3cd49fd7da79541a1e87bfa5750f5a939c6626df
tree3263448f7a463b126c4ae6250e8da3d10dd906a0
parent553e4c5591f1e94519ca299aec0c1576f5cede9f
perf: Drop sample rate when sampling is too slow

commit 14c63f17b1fde5a575a28e96547a22b451c71fb5 upstream.

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>
Cc: Weng Meiling <wengmeiling.weng@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Documentation/sysctl/kernel.txt
arch/x86/kernel/cpu/perf_event.c
include/linux/perf_event.h
kernel/events/core.c
kernel/sysctl.c