[PATCH] x86, perf, bts: disable BTS from Nehalem to Ivy Bridge

[PATCH] x86, perf, bts: disable BTS from Nehalem to Ivy Bridge

[markus.t.metzger]

From: Markus Metzger <markus.t.metzger@intel.com>

Starting with Nehalem, the BTS "from" information may in some cases be
incorrect (AAJ122).

This has been detected while adding branch tracing support to gdb, where it
results in sporadic test fails.

Disable BTS support on Nehalem, Westmere, Sandy Bridge, and Ivy Bridge.

CC: Mark Kettenis <kettenis@gnu.org>
CC: Pedro Alves <palves@redhat.com>
CC: Jan Kratochvil <jan.kratochvil@redhat.com>
CC: gdb-patches@sourceware.org
Signed-off-by: Markus Metzger <markus.t.metzger@intel.com>
---
 arch/x86/kernel/cpu/perf_event_intel.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c
index 6bca492..e72aac9 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1893,6 +1893,16 @@ static __init void intel_nehalem_quirk(void)
 	}
 }
 
+static __init void intel_disable_bts(void)
+{
+	/*
+	 * Erratum AAJ122: LBR, BTM, or BTS records may have incorrect branch
+	 * "from" information afer an EIST transition, T-states, C1E, or
+	 * Adaptive Thermal Throttling.
+	 */
+	x86_pmu.bts = 0;
+}
+
 __init int intel_pmu_init(void)
 {
 	union cpuid10_edx edx;
@@ -2003,6 +2013,7 @@ __init int intel_pmu_init(void)
 			X86_CONFIG(.event=0xb1, .umask=0x3f, .inv=1, .cmask=1);
 
 		x86_add_quirk(intel_nehalem_quirk);
+		intel_disable_bts();
 
 		pr_cont("Nehalem events, ");
 		break;
@@ -2042,6 +2053,7 @@ __init int intel_pmu_init(void)
 		intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] =
 			X86_CONFIG(.event=0xb1, .umask=0x3f, .inv=1, .cmask=1);
 
+		intel_disable_bts();
 		pr_cont("Westmere events, ");
 		break;
 
@@ -2070,6 +2082,7 @@ __init int intel_pmu_init(void)
 		intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] =
 			X86_CONFIG(.event=0xb1, .umask=0x01, .inv=1, .cmask=1);
 
+		intel_disable_bts();
 		pr_cont("SandyBridge events, ");
 		break;
 	case 58: /* IvyBridge */
@@ -2092,6 +2105,7 @@ __init int intel_pmu_init(void)
 		intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] =
 			X86_CONFIG(.event=0x0e, .umask=0x01, .inv=1, .cmask=1);
 
+		intel_disable_bts();
 		pr_cont("IvyBridge events, ");
 		break;
 
-- 
1.7.1

Re: [PATCH] x86, perf, bts: disable BTS from Nehalem to Ivy Bridge

[Ingo Molnar]

* markus.t.metzger@intel.com <markus.t.metzger@intel.com> wrote:

> From: Markus Metzger <markus.t.metzger@intel.com>
> 
> Starting with Nehalem, the BTS "from" information may in some cases be
> incorrect (AAJ122).
> 
> This has been detected while adding branch tracing support to gdb, where it
> results in sporadic test fails.
> 
> Disable BTS support on Nehalem, Westmere, Sandy Bridge, and Ivy Bridge.

But the failures are rare, so the BTS data is still correct 
statistically, by and large, right? So why not just keep it 
as-is and teach tooling to be more robust about implausible 
trace entries? It has to be ready for that eventuality *anyway*.

Thanks,

	Ingo

RE: [PATCH] x86, perf, bts: disable BTS from Nehalem to Ivy Bridge

[Metzger, Markus T]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Ingo Molnar
> Sent: Thursday, January 24, 2013 4:47 PM


> > Starting with Nehalem, the BTS "from" information may in some cases be
> > incorrect (AAJ122).
> >
> > This has been detected while adding branch tracing support to gdb, where it
> > results in sporadic test fails.
> >
> > Disable BTS support on Nehalem, Westmere, Sandy Bridge, and Ivy Bridge.
> 
> But the failures are rare, so the BTS data is still correct
> statistically, by and large, right? So why not just keep it
> as-is and teach tooling to be more robust about implausible
> trace entries? It has to be ready for that eventuality *anyway*.

Yes, the fails are rare. They are frequent enough, however, to cause sporadic test fails.

The problem is that you can't reliably detect such fails. In the worst case, GDB would show wrong but plausible trace. Typically, GDB just shows garbage (i.e. impossible trace) in such cases.

I'm afraid one might endlessly debate whether the feature as-is is useful or not. It is working fine on Atom so I chose to disable it on core.

The GDB folks would rather not disable the feature inside GDB; they prefer that it is disabled in the kernel. There will be an additional check inside GDB to support older kernel versions.

Regards,
markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052