> > So can just drop the XXX comment. Ok?
>
> How about hiding the entire thing in a hsw function. I'm fairly sure
> that eventually we'll need to check all counters for this nonsense.
AFAIK there are no plans to do so.
>
> Something like so perhaps?
It's ok for me, except it's not for TSX
On Fri, Aug 30, 2013 at 01:44:45PM -0700, Andi Kleen wrote:
> On Fri, Aug 30, 2013 at 06:02:15PM +0200, Peter Zijlstra wrote:
> > On Wed, Aug 21, 2013 at 04:47:23PM -0700, Andi Kleen wrote:
> > > @@ -1224,6 +1240,15 @@ again:
> > > x86_pmu.drain_pebs(regs);
> > > }
> > >
> > > + /*
>
On Fri, Aug 30, 2013 at 01:44:45PM -0700, Andi Kleen wrote:
On Fri, Aug 30, 2013 at 06:02:15PM +0200, Peter Zijlstra wrote:
On Wed, Aug 21, 2013 at 04:47:23PM -0700, Andi Kleen wrote:
@@ -1224,6 +1240,15 @@ again:
x86_pmu.drain_pebs(regs);
}
+ /*
+ * To avoid
So can just drop the XXX comment. Ok?
How about hiding the entire thing in a hsw function. I'm fairly sure
that eventually we'll need to check all counters for this nonsense.
AFAIK there are no plans to do so.
Something like so perhaps?
It's ok for me, except it's not for TSX (that's
On Fri, Aug 30, 2013 at 06:02:15PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 21, 2013 at 04:47:23PM -0700, Andi Kleen wrote:
> > @@ -1224,6 +1240,15 @@ again:
> > x86_pmu.drain_pebs(regs);
> > }
> >
> > + /*
> > +* To avoid spurious interrupts with perf stat always reset
On Wed, Aug 21, 2013 at 04:47:23PM -0700, Andi Kleen wrote:
> @@ -1224,6 +1240,15 @@ again:
> x86_pmu.drain_pebs(regs);
> }
>
> + /*
> + * To avoid spurious interrupts with perf stat always reset checkpointed
> + * counters.
> + *
> + * XXX move
On Wed, Aug 21, 2013 at 04:47:23PM -0700, Andi Kleen wrote:
@@ -1224,6 +1240,15 @@ again:
x86_pmu.drain_pebs(regs);
}
+ /*
+ * To avoid spurious interrupts with perf stat always reset checkpointed
+ * counters.
+ *
+ * XXX move somewhere else.
On Fri, Aug 30, 2013 at 06:02:15PM +0200, Peter Zijlstra wrote:
On Wed, Aug 21, 2013 at 04:47:23PM -0700, Andi Kleen wrote:
@@ -1224,6 +1240,15 @@ again:
x86_pmu.drain_pebs(regs);
}
+ /*
+* To avoid spurious interrupts with perf stat always reset checkpointed
From: Andi Kleen
With checkpointed counters there can be a situation where the counter
is overflowing, aborts the transaction, is set back to a non overflowing
checkpoint, causes interupt. The interrupt doesn't see the overflow
because it has been checkpointed. This is then a spurious PMI,
From: Andi Kleen a...@linux.intel.com
With checkpointed counters there can be a situation where the counter
is overflowing, aborts the transaction, is set back to a non overflowing
checkpoint, causes interupt. The interrupt doesn't see the overflow
because it has been checkpointed. This is then
From: Andi Kleen
With checkpointed counters there can be a situation where the counter
is overflowing, aborts the transaction, is set back to a non overflowing
checkpoint, causes interupt. The interrupt doesn't see the overflow
because it has been checkpointed. This is then a spurious PMI,
From: Andi Kleen a...@linux.intel.com
With checkpointed counters there can be a situation where the counter
is overflowing, aborts the transaction, is set back to a non overflowing
checkpoint, causes interupt. The interrupt doesn't see the overflow
because it has been checkpointed. This is then
On Thu, Aug 08, 2013 at 06:15:43PM -0700, Andi Kleen wrote:
> +++ b/arch/x86/kernel/cpu/perf_event_intel.c
> @@ -1141,6 +1146,17 @@ static void intel_pmu_enable_event(struct perf_event
> *event)
> int intel_pmu_save_and_restart(struct perf_event *event)
> {
>
On Thu, Aug 08, 2013 at 06:15:43PM -0700, Andi Kleen wrote:
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1141,6 +1146,17 @@ static void intel_pmu_enable_event(struct perf_event
*event)
int intel_pmu_save_and_restart(struct perf_event *event)
{
x86_perf_event_update(event);
+
From: Andi Kleen
With checkpointed counters there can be a situation where the counter
is overflowing, aborts the transaction, is set back to a non overflowing
checkpoint, causes interupt. The interrupt doesn't see the overflow
because it has been checkpointed. This is then a spurious PMI,
From: Andi Kleen a...@linux.intel.com
With checkpointed counters there can be a situation where the counter
is overflowing, aborts the transaction, is set back to a non overflowing
checkpoint, causes interupt. The interrupt doesn't see the overflow
because it has been checkpointed. This is then
16 matches
Mail list logo
