[PATCH 1/2] oprofile: Add HAVE_OPROFILE_NMI_TIMER

HAVE_PERF_EVENTS_NMI is used for two things - the oprofile NMI timer
and the hardlockup detector.

Create HAVE_OPROFILE_NMI_TIMER so an architecture can select them
separately. On ppc64 we want to add the hardlockup detector, but not
the oprofile NMI timer fallback.

Signed-off-by: Anton Blanchard <redacted>
---
 arch/Kconfig     | 5 ++++-
 arch/x86/Kconfig | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 05d7a8a..3d50e42 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig

@@ -30,9 +30,12 @@ config OPROFILE_EVENT_MULTIPLEX
 config HAVE_OPROFILE
 	bool
 
+config HAVE_OPROFILE_NMI_TIMER
+	bool
+
 config OPROFILE_NMI_TIMER
 	def_bool y
-	depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
+	depends on PERF_EVENTS && HAVE_OPROFILE_NMI_TIMER
 
 config KPROBES
 	bool "Kprobes"

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ba397bd..98d9c72 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig

@@ -138,6 +138,7 @@ config X86
 	select HAVE_ACPI_APEI_NMI if ACPI
 	select ACPI_LEGACY_TABLES_LOOKUP if ACPI
 	select X86_FEATURE_NAMES if PROC_FS
+	select HAVE_OPROFILE_NMI_TIMER
 
 config INSTRUCTION_DECODER
 	def_bool y

-- 
2.1.0

The hard lockup detector uses a PMU event as a periodic NMI to
detect if we are stuck (where stuck means no timer interrupts have
occurred).

Ben's rework of the ppc64 soft disable code has made ppc64 PMU
exceptions a partial NMI. They can get disabled if an external
interrupt comes in, but otherwise PMU interrupts will fire in
interrupt disabled regions.

We disable the hard lockup detector by default for a few reasons:

- It breaks userspace event based branches on POWER8.
- It is likely to produce false positives on KVM guests.
- Since PMCs can only count to 2^31, counting cycles means we might
  take multiple PMU exceptions per second per hardware thread even
  if our hard lockup timeout is 10 seconds.

It can be enabled via a boot option, or via procfs.

Signed-off-by: Anton Blanchard <redacted>
---
 arch/powerpc/Kconfig           |  1 +
 arch/powerpc/include/asm/nmi.h |  4 ++++
 arch/powerpc/kernel/setup_64.c | 20 ++++++++++++++++++++
 3 files changed, 25 insertions(+)
 create mode 100644 arch/powerpc/include/asm/nmi.h

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a2a168e..f6f4734 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig

@@ -152,6 +152,7 @@ config PPC
 	select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
 	select NO_BOOTMEM
 	select HAVE_GENERIC_RCU_GUP
+	select HAVE_PERF_EVENTS_NMI if PPC64
 
 config GENERIC_CSUM
 	def_bool CPU_LITTLE_ENDIAN

diff --git a/arch/powerpc/include/asm/nmi.h b/arch/powerpc/include/asm/nmi.h
new file mode 100644
index 0000000..ff1ccb3
--- /dev/null
+++ b/arch/powerpc/include/asm/nmi.h

@@ -0,0 +1,4 @@
+#ifndef _ASM_NMI_H
+#define _ASM_NMI_H
+
+#endif /* _ASM_NMI_H */

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 300be7d..ae39ec6 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c

@@ -37,6 +37,7 @@
 #include <linux/memblock.h>
 #include <linux/hugetlb.h>
 #include <linux/memory.h>
+#include <linux/nmi.h>
 
 #include <asm/io.h>
 #include <asm/kdump.h>

@@ -779,3 +780,22 @@ unsigned long memory_block_size_bytes(void)
 struct ppc_pci_io ppc_pci_io;
 EXPORT_SYMBOL(ppc_pci_io);
 #endif
+
+#ifdef CONFIG_HARDLOCKUP_DETECTOR
+u64 hw_nmi_get_sample_period(int watchdog_thresh)
+{
+	return ppc_proc_freq * watchdog_thresh;
+}
+
+/*
+ * The hardlockup detector breaks PMU event based branches and is likely
+ * to get false positives in KVM guests, so disable it by default.
+ */
+static int __init disable_hardlockup_detector(void)
+{
+	watchdog_enable_hardlockup_detector(false);
+
+	return 0;
+}
+early_initcall(disable_hardlockup_detector);
+#endif

-- 
2.1.0

HAVE_PERF_EVENTS_NMI is used for two things - the oprofile NMI timer
and the hard lockup detector.

Create HAVE_OPROFILE_NMI_TIMER so an architecture can select them
separately. On ppc64 we want to add the hard lockup detector, but not
the oprofile NMI timer fallback.

Signed-off-by: Anton Blanchard <redacted>
---

Resending, because I forgot to cc the x86 guys.

How would you like us to handle it? Michael Ellerman says
we can put it in a topic branch, or just merge it and cop
any conflicts.

diff --git a/arch/Kconfig b/arch/Kconfig
index 05d7a8a..3d50e42 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig

@@ -30,9 +30,12 @@ config OPROFILE_EVENT_MULTIPLEX
 config HAVE_OPROFILE
 	bool
 
+config HAVE_OPROFILE_NMI_TIMER
+	bool
+
 config OPROFILE_NMI_TIMER
 	def_bool y
-	depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
+	depends on PERF_EVENTS && HAVE_OPROFILE_NMI_TIMER
 
 config KPROBES
 	bool "Kprobes"

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ba397bd..98d9c72 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig

@@ -138,6 +138,7 @@ config X86
 	select HAVE_ACPI_APEI_NMI if ACPI
 	select ACPI_LEGACY_TABLES_LOOKUP if ACPI
 	select X86_FEATURE_NAMES if PROC_FS
+	select HAVE_OPROFILE_NMI_TIMER
 
 config INSTRUCTION_DECODER
 	def_bool y

-- 
2.1.0

On 21.01.15 22:54:08, Anton Blanchard wrote:

HAVE_PERF_EVENTS_NMI is used for two things - the oprofile NMI timer
and the hard lockup detector.

Create HAVE_OPROFILE_NMI_TIMER so an architecture can select them
separately. On ppc64 we want to add the hard lockup detector, but not
the oprofile NMI timer fallback.

No, this option should depend on HAVE_PERF_EVENTS_NMI. It uses a perf
counter internally, so if perf supports some sort of 'soft' nmi,
oprofile nmi timer would also work well with it.

I also don't see a reason, why you don't want to support oprofile NMI
timer. Is there any?

 config OPROFILE_NMI_TIMER
 	def_bool y
-	depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
+	depends on PERF_EVENTS && HAVE_OPROFILE_NMI_TIMER

I understand that you might want to disable NMI_TIMER, though I really
don't see a reason if oprofile is enabled and can support it.

If you don't want NMI_TIMER being enabled, then (order of preference):

 * disable it with oprofile (OPROFILE dependency needed for
   NMI_TIMER), or

 * make the default value for NMI_TIMER !PPC64 and add a prompt to let
   the user select/deselect it, or

 * disable OPROFILE_NMI_TIMER by adding a !PPC64 dependency.

-Robert

Hi Robert,

I also don't see a reason, why you don't want to support oprofile NMI
timer. Is there any?

I couldn't come up with a case where it would be a benefit to us. We
roll out PMU support for a new CPU early so that the kernel and tools
support it when we GA. On the other hand adding oprofile NMI support
will put pressure on us to add more test cases.

If you don't want NMI_TIMER being enabled, then (order of preference):

 * disable it with oprofile (OPROFILE dependency needed for
   NMI_TIMER), or

 * make the default value for NMI_TIMER !PPC64 and add a prompt to let
   the user select/deselect it, or

 * disable OPROFILE_NMI_TIMER by adding a !PPC64 dependency.

I'll rework and resubmit. Thanks.

Anton