Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1253199 > unrolled thread

[PATCH 1/3] x86, perf: Use a new PMU ack sequence

Back to article view | Back to linux.kernel

Contents

  [PATCH 1/3] x86, perf: Use a new PMU ack sequence Andi Kleen <andi@firstfloor.org> - 2015-10-21 22:20 +0200
    [PATCH 2/3] x86, perf: Factor out BTS enable/disable functions Andi Kleen <andi@firstfloor.org> - 2015-10-21 22:20 +0200
    Re: [PATCH 1/3] x86, perf: Use a new PMU ack sequence Peter Zijlstra <peterz@infradead.org> - 2015-10-21 22:40 +0200
      Re: [PATCH 1/3] x86, perf: Use a new PMU ack sequence Andi Kleen <ak@linux.intel.com> - 2015-10-21 23:50 +0200
        Re: [PATCH 1/3] x86, perf: Use a new PMU ack sequence Ingo Molnar <mingo@kernel.org> - 2015-10-22 11:30 +0200

#1253199 — [PATCH 1/3] x86, perf: Use a new PMU ack sequence

From: Andi Kleen <ak@linux.intel.com>

The SKL PMU code had a problem with LBR freezing. When a counter
overflows already in the PMI handler, the LBR would be frozen
early and not be unfrozen until the next PMI. This means we would
get stale LBR information.

Depending on the workload this could happen for a few percent
of the PMIs for cycles in adaptive frequency mode, because the frequency
algorithm regularly goes down to very low periods.

This patch implements a new PMU ack sequence that avoids this problem.
The new sequence is:

- (counters are disabled with GLOBAL_CTRL)
There should be no further increments of the counters by later instructions; and
thus no additional PMI (and thus no additional freezing).

- ack the APIC

Clear the APIC PMI LVT entry so that any later interrupt is delivered and is
not lost due to the PMI LVT entry being masked. A lost PMI interrupt could lead to
LBRs staying frozen without entering the PMI handler

- Ack the PMU counters. This unfreezes the LBRs on Skylake (but not
on earlier CPUs which rely on DEBUGCTL writes for this)

- Reenable counters

The WRMSR will start the counters counting again (and will be ordered after the
APIC LVT PMI entry write since WRMSR is architecturally serializing). Since the
APIC PMI LVT is unmasked, any PMI which is caused by these perfmon counters
will trigger an NMI (but the delivery may be delayed until after the next
IRET)

One side effect is that the old retry loop is not possible anymore,
as the counters stay unacked for the majority of the PMI handler,
but that is not a big loss, as "profiling" the PMI was always
a bit dubious. For the old ack sequence it is still supported.

The new sequence is now used unconditionally on all Intel Core/Atom
CPUs. The old irq loop check is removed. Instead we rely on the
generic nmi maximum duration check in the NMI code, together with the perf
enforcement of the maximum sampling rate, to stop any runaway
counters. We also assume that any counter can be stopped by setting
a sufficiently large overflow value.

v2:
Use new ack sequence unconditionally. Remove pmu reset code.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 arch/x86/kernel/cpu/perf_event.h       |  1 -
 arch/x86/kernel/cpu/perf_event_intel.c | 82 +++++-----------------------------
 2 files changed, 11 insertions(+), 72 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 499f533..6388540 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -550,7 +550,6 @@ struct x86_pmu {
 	struct event_constraint *event_constraints;
 	struct x86_pmu_quirk *quirks;
 	int		perfctr_second_write;
-	bool		late_ack;
 	unsigned	(*limit_period)(struct perf_event *event, unsigned l);
 
 	/*
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c
index f63360b..68a37b5 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1741,44 +1741,6 @@ int intel_pmu_save_and_restart(struct perf_event *event)
 	return x86_perf_event_set_period(event);
 }
 
-static void intel_pmu_reset(void)
-{
-	struct debug_store *ds = __this_cpu_read(cpu_hw_events.ds);
-	unsigned long flags;
-	int idx;
-
-	if (!x86_pmu.num_counters)
-		return;
-
-	local_irq_save(flags);
-
-	pr_info("clearing PMU state on CPU#%d\n", smp_processor_id());
-
-	for (idx = 0; idx < x86_pmu.num_counters; idx++) {
-		wrmsrl_safe(x86_pmu_config_addr(idx), 0ull);
-		wrmsrl_safe(x86_pmu_event_addr(idx),  0ull);
-	}
-	for (idx = 0; idx < x86_pmu.num_counters_fixed; idx++)
-		wrmsrl_safe(MSR_ARCH_PERFMON_FIXED_CTR0 + idx, 0ull);
-
-	if (ds)
-		ds->bts_index = ds->bts_buffer_base;
-
-	/* Ack all overflows and disable fixed counters */
-	if (x86_pmu.version >= 2) {
-		intel_pmu_ack_status(intel_pmu_get_status());
-		wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
-	}
-
-	/* Reset LBRs and LBR freezing */
-	if (x86_pmu.lbr_nr) {
-		update_debugctlmsr(get_debugctlmsr() &
-			~(DEBUGCTLMSR_FREEZE_LBRS_ON_PMI|DEBUGCTLMSR_LBR));
-	}
-
-	local_irq_restore(flags);
-}
-
 /*
  * This handler is triggered by the local APIC, so the APIC IRQ handling
  * rules apply:
@@ -1787,39 +1749,22 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
 {
 	struct perf_sample_data data;
 	struct cpu_hw_events *cpuc;
-	int bit, loops;
+	int bit;
 	u64 status;
+	u64 orig_status;
 	int handled;
 
 	cpuc = this_cpu_ptr(&cpu_hw_events);
 
-	/*
-	 * No known reason to not always do late ACK,
-	 * but just in case do it opt-in.
-	 */
-	if (!x86_pmu.late_ack)
-		apic_write(APIC_LVTPC, APIC_DM_NMI);
 	__intel_pmu_disable_all();
 	handled = intel_pmu_drain_bts_buffer();
 	handled += intel_bts_interrupt();
 	status = intel_pmu_get_status();
+	orig_status = status;
 	if (!status)
 		goto done;
 
-	loops = 0;
-again:
 	intel_pmu_lbr_read();
-	intel_pmu_ack_status(status);
-	if (++loops > 100) {
-		static bool warned = false;
-		if (!warned) {
-			WARN(1, "perfevents: irq loop stuck!\n");
-			perf_event_print_debug();
-			warned = true;
-		}
-		intel_pmu_reset();
-		goto done;
-	}
 
 	inc_irq_stat(apic_perf_irqs);
 
@@ -1877,22 +1822,20 @@ again:
 			x86_pmu_stop(event, 0);
 	}
 
-	/*
-	 * Repeat if there is more work to be done:
-	 */
-	status = intel_pmu_get_status();
-	if (status)
-		goto again;
-
 done:
-	__intel_pmu_enable_all(0, true);
 	/*
 	 * Only unmask the NMI after the overflow counters
 	 * have been reset. This avoids spurious NMIs on
 	 * Haswell CPUs.
 	 */
-	if (x86_pmu.late_ack)
-		apic_write(APIC_LVTPC, APIC_DM_NMI);
+	apic_write(APIC_LVTPC, APIC_DM_NMI);
+
+	/*
+	 * Ack the PMU late. This avoids bogus freezing
+	 * on Skylake CPUs.
+	 */
+	intel_pmu_ack_status(orig_status);
+	__intel_pmu_enable_all(0, true);
 	return handled;
 }
 
@@ -3455,7 +3398,6 @@ __init int intel_pmu_init(void)
 	case 69: /* 22nm Haswell ULT */
 	case 70: /* 22nm Haswell + GT3e (Intel Iris Pro graphics) */
 		x86_add_quirk(intel_ht_bug);
-		x86_pmu.late_ack = true;
 		memcpy(hw_cache_event_ids, hsw_hw_cache_event_ids, sizeof(hw_cache_event_ids));
 		memcpy(hw_cache_extra_regs, hsw_hw_cache_extra_regs, sizeof(hw_cache_extra_regs));
 
@@ -3480,7 +3422,6 @@ __init int intel_pmu_init(void)
 	case 86: /* 14nm Broadwell Xeon D */
 	case 71: /* 14nm Broadwell + GT3e (Intel Iris Pro graphics) */
 	case 79: /* 14nm Broadwell Server */
-		x86_pmu.late_ack = true;
 		memcpy(hw_cache_event_ids, hsw_hw_cache_event_ids, sizeof(hw_cache_event_ids));
 		memcpy(hw_cache_extra_regs, hsw_hw_cache_extra_regs, sizeof(hw_cache_extra_regs));
 
@@ -3513,7 +3454,6 @@ __init int intel_pmu_init(void)
 
 	case 78: /* 14nm Skylake Mobile */
 	case 94: /* 14nm Skylake Desktop */
-		x86_pmu.late_ack = true;
 		memcpy(hw_cache_event_ids, skl_hw_cache_event_ids, sizeof(hw_cache_event_ids));
 		memcpy(hw_cache_extra_regs, skl_hw_cache_extra_regs, sizeof(hw_cache_extra_regs));
 		intel_pmu_lbr_init_skl();
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1253201 — [PATCH 2/3] x86, perf: Factor out BTS enable/disable functions

From: Andi Kleen <ak@linux.intel.com>

Move BTS enable/disable into own functions. Used by the next
patch.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 arch/x86/kernel/cpu/perf_event_intel.c | 43 ++++++++++++++++++++--------------
 1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c
index 68a37b5..31323cc 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1457,20 +1457,39 @@ static __initconst const u64 slm_hw_cache_event_ids
  },
 };
 
-/*
- * Use from PMIs where the LBRs are already disabled.
- */
-static void __intel_pmu_disable_all(void)
+static inline void intel_pmu_maybe_disable_bts(void)
 {
 	struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
 
-	wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
-
 	if (test_bit(INTEL_PMC_IDX_FIXED_BTS, cpuc->active_mask))
 		intel_pmu_disable_bts();
 	else
 		intel_bts_disable_local();
+}
+
+static inline void intel_pmu_maybe_enable_bts(void)
+{
+	struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
 
+	if (test_bit(INTEL_PMC_IDX_FIXED_BTS, cpuc->active_mask)) {
+		struct perf_event *event =
+			cpuc->events[INTEL_PMC_IDX_FIXED_BTS];
+
+		if (WARN_ON_ONCE(!event))
+			return;
+
+		intel_pmu_enable_bts(event->hw.config);
+	} else
+		intel_bts_enable_local();
+}
+
+/*
+ * Use from PMIs where the LBRs are already disabled.
+ */
+static void __intel_pmu_disable_all(void)
+{
+	wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+	intel_pmu_maybe_disable_bts();
 	intel_pmu_pebs_disable_all();
 }
 
@@ -1488,17 +1507,7 @@ static void __intel_pmu_enable_all(int added, bool pmi)
 	intel_pmu_lbr_enable_all(pmi);
 	wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL,
 			x86_pmu.intel_ctrl & ~cpuc->intel_ctrl_guest_mask);
-
-	if (test_bit(INTEL_PMC_IDX_FIXED_BTS, cpuc->active_mask)) {
-		struct perf_event *event =
-			cpuc->events[INTEL_PMC_IDX_FIXED_BTS];
-
-		if (WARN_ON_ONCE(!event))
-			return;
-
-		intel_pmu_enable_bts(event->hw.config);
-	} else
-		intel_bts_enable_local();
+	intel_pmu_maybe_enable_bts();
 }
 
 static void intel_pmu_enable_all(int added)
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253222

On Wed, Oct 21, 2015 at 01:16:06PM -0700, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> 
> The SKL PMU code had a problem with LBR freezing. When a counter
> overflows already in the PMI handler, the LBR would be frozen
> early and not be unfrozen until the next PMI. This means we would
> get stale LBR information.
> 
> Depending on the workload this could happen for a few percent
> of the PMIs for cycles in adaptive frequency mode, because the frequency
> algorithm regularly goes down to very low periods.
> 
> This patch implements a new PMU ack sequence that avoids this problem.
> The new sequence is:
> 
> - (counters are disabled with GLOBAL_CTRL)
> There should be no further increments of the counters by later instructions; and
> thus no additional PMI (and thus no additional freezing).
> 
> - ack the APIC
> 
> Clear the APIC PMI LVT entry so that any later interrupt is delivered and is
> not lost due to the PMI LVT entry being masked. A lost PMI interrupt could lead to
> LBRs staying frozen without entering the PMI handler
> 
> - Ack the PMU counters. This unfreezes the LBRs on Skylake (but not
> on earlier CPUs which rely on DEBUGCTL writes for this)
> 
> - Reenable counters
> 
> The WRMSR will start the counters counting again (and will be ordered after the
> APIC LVT PMI entry write since WRMSR is architecturally serializing). Since the
> APIC PMI LVT is unmasked, any PMI which is caused by these perfmon counters
> will trigger an NMI (but the delivery may be delayed until after the next
> IRET)
> 
> One side effect is that the old retry loop is not possible anymore,
> as the counters stay unacked for the majority of the PMI handler,
> but that is not a big loss, as "profiling" the PMI was always
> a bit dubious. For the old ack sequence it is still supported.
> 
> The new sequence is now used unconditionally on all Intel Core/Atom
> CPUs. The old irq loop check is removed. Instead we rely on the
> generic nmi maximum duration check in the NMI code, together with the perf
> enforcement of the maximum sampling rate, to stop any runaway
> counters. We also assume that any counter can be stopped by setting
> a sufficiently large overflow value.
> 
> v2:
> Use new ack sequence unconditionally. Remove pmu reset code.

So this is not something we can easily revert if things go bad. Esp.
since you build on it with the next patches.

Also, teach your editor to wrap at 72 chars for Changelogs.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253279

> > v2:
> > Use new ack sequence unconditionally. Remove pmu reset code.
> 
> So this is not something we can easily revert if things go bad. Esp.
> since you build on it with the next patches.

Ok, and?

You want me to go back to the previous patch? That one is easily
undoable (just disable the flag for the model)

Another alternative would be to fork the PMI handler into a new and
an old version, that is switchable.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1253646

* Andi Kleen <ak@linux.intel.com> wrote:

> > > v2:
> > > Use new ack sequence unconditionally. Remove pmu reset code.
> > 
> > So this is not something we can easily revert if things go bad. Esp.
> > since you build on it with the next patches.
> 
> Ok, and?

Sigh, you are being disruptive again.

> You want me to go back to the previous patch? That one is easily
> undoable (just disable the flag for the model)
> 
> Another alternative would be to fork the PMI handler into a new and
> an old version, that is switchable.

Here you pretend that you didn't read the sane solution that was suggested to you 
just three days ago:

  http://lkml.kernel.org/r/20151019070812.GB17855@gmail.com

  " > > Ingo, do you want to first merge the safe patch and then clean up?
    >
    > Yeah, would be nice to structure it that way, out of general paranoia.
  "

I.e. first apply the safe approach, then, after the dependent changes, clean it up 
by introducing the dangerous change.

The thing is, I'm close to summarily NAK-ing any patches from you to the perf 
subsystem, due to the unacceptably low quality patches combined with obtuse 
passive-aggressive obstruction you are routinely burdening maintainers with.

Btw., I noticed that you routinely don't Cc me to perf patches. Please always Cc: 
me to perf patches (both kernel and tooling patches). I still will not apply them 
directly, only if another perf maintainer signs off on them, but I'd like to have 
a record of all your submissions.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web