Re: [PATCH 9/9] x86, perf: Move PMU ACK after LBR read

[Andi Kleen <ak@linux.intel.com>]

On Mon, May 11, 2015 at 09:43:41AM -0700, Stephane Eranian wrote:
> On Mon, May 11, 2015 at 9:36 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Mon, May 11, 2015 at 09:32:33AM -0700, Stephane Eranian wrote:
> >> >> This is a minimal change. In principle the ACK could be moved much later.
> >> >
> >> > Right, so the more complete change would be to use the new and improved
> >> > FREEZE_ON_PMI and reenable both the LBRs and the CTRs with the
> >> > STATUS_RESET MSR, right?
> >> >
> >> > Does it make sense to have a new handle_irq() routine for that?
> >>
> >> Were we not already using FREEZE_ON_PMI with LBR (except for one
> >> erratum on HSW)?
> >
> > That's FREEZE_LBRS_ON_PMI, I was referring to FREEZE_PERFMON_ON_PMI,
> > which we've not used so far.
> >
> Ah, yes that one was not used so far. I don't quite remember why.
> I think with PEBS, you don't need it or it should be off or something like this.

The LBR freeze should work with call stack mode if you use PEBS events.
So in theory we could allow call-stack lbr for kernel with such a restriction.
But we have a working kernel backtrace anyways, so it's not really critical.

> 
> > I think Andi tried using it before, but there's some issues with it on
> > v3, but v4 should have fixed all that.
> >
> I was referring to a LBR issue on v3 (HSW) and call stack mode.
> 
> > Andi can you perhaps explain what the problem with FREEZE_PERFMON_ON_PMI
> > on v3 was again?

I'm not sure why we never used it.
The update of the DEBUGCTL can race with other operations, but it's rather
obscure.

But I would not do it right now.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only