Re: [PATCH 3/5] perf, x86: Disable PEBS on clowertown chips

From: Stephane Eranian
Date: Fri Mar 05 2010 - 13:59:32 EST


On Fri, Mar 5, 2010 at 7:39 AM, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:
> This CPU has just too many handycaps to be really useful.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
> ---
> Âarch/x86/kernel/cpu/perf_event.c    |  Â4 ++++
> Âarch/x86/kernel/cpu/perf_event_intel.c | Â 27 +++++++++++++++++++++++++++
> Â2 files changed, 31 insertions(+)
>
> Index: linux-2.6/arch/x86/kernel/cpu/perf_event.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/cpu/perf_event.c
> +++ linux-2.6/arch/x86/kernel/cpu/perf_event.c
> @@ -197,6 +197,7 @@ struct x86_pmu {
>    Âvoid      Â(*put_event_constraints)(struct cpu_hw_events *cpuc,
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â struct perf_event *event);
> Â Â Â Âstruct event_constraint *event_constraints;
> +    void      Â(*quirks)(void);
>
>    Âvoid      Â(*cpu_prepare)(int cpu);
>    Âvoid      Â(*cpu_starting)(int cpu);
> @@ -1380,6 +1381,9 @@ void __init init_hw_perf_events(void)
>
> Â Â Â Âpr_cont("%s PMU driver.\n", x86_pmu.name);
>
> + Â Â Â if (x86_pmu.quirks)
> + Â Â Â Â Â Â Â x86_pmu.quirks();
> +
> Â Â Â Âif (x86_pmu.num_events > X86_PMC_MAX_GENERIC) {
> Â Â Â Â Â Â Â ÂWARN(1, KERN_ERR "hw perf events %d > max(%d), clipping!",
> Â Â Â Â Â Â Â Â Â Â x86_pmu.num_events, X86_PMC_MAX_GENERIC);
> Index: linux-2.6/arch/x86/kernel/cpu/perf_event_intel.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/cpu/perf_event_intel.c
> +++ linux-2.6/arch/x86/kernel/cpu/perf_event_intel.c
> @@ -800,6 +800,32 @@ static __initconst struct x86_pmu intel_
>    Â.cpu_dying       Â= fini_debug_store_on_cpu,
> Â};
>
> +static void intel_clowertown_quirks(void)
> +{
> + Â Â Â /*
> + Â Â Â Â* PEBS is unreliable due to:
> + Â Â Â Â*
> + Â Â Â Â* Â AJ67 Â- PEBS may experience CPL leaks
> + Â Â Â Â* Â AJ68 Â- PEBS PMI may be delayed by one event
> + Â Â Â Â* Â AJ69 Â- GLOBAL_STATUS[62] will only be set when DEBUGCTL[12]
> + Â Â Â Â* Â AJ106 - FREEZE_LBRS_ON_PMI doesn't work in combination with PEBS
> + Â Â Â Â*
> + Â Â Â Â* AJ67 could be worked around by restricting the OS/USR flags.
> + Â Â Â Â* AJ69 could be worked around by setting PMU_FREEZE_ON_PMI.
> + Â Â Â Â*
> + Â Â Â Â* AJ106 could possibly be worked around by not allowing LBR
> + Â Â Â Â* Â Â Â usage from PEBS, including the fixup.
> + Â Â Â Â* AJ68 Âcould possibly be worked around by always programming
> + Â Â Â Â* Â Â Â a pebs_event_reset[0] value and coping with the lost events.
> + Â Â Â Â*
> + Â Â Â Â* But taken together it might just make sense to not enable PEBS on
> + Â Â Â Â* these chips.
> + Â Â Â Â*/
> + Â Â Â printk(KERN_WARNING "PEBS disabled due to CPU errata.\n");
> + Â Â Â x86_pmu.pebs = 0;
> + Â Â Â x86_pmu.pebs_constraints = NULL;
> +}
> +
> Âstatic __init int intel_pmu_init(void)
> Â{
> Â Â Â Âunion cpuid10_edx edx;
> @@ -864,6 +890,7 @@ static __init int intel_pmu_init(void)
> Â Â Â Â Â Â Â Âbreak;
>
> Â Â Â Âcase 15: /* original 65 nm celeron/pentium/core2/xeon, "Merom"/"Conroe" */
> + Â Â Â Â Â Â Â x86_pmu.quirks = intel_clowertown_quirks;

That's too coarse grain!
It is more subtle than this. Some of the errata are marked as Plan
fix. They seem to be
fixed in later models. Your looking at the E5xxx series errata but the
E7xxx do not have
the same problems.

As for CPL leaking, you get that also with regular sampling when you
execute near
the user/kernel boundary given you have skid. Either the kernel or the
user has to
drop samples.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/