From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: Jiri Olsa <jolsa@redhat.com>, Andi Kleen <ak@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
"mingo@elte.hu" <mingo@elte.hu>,
"Liang, Kan" <kan.liang@intel.com>,
Namhyung Kim <namhyung@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [PATCH 2/3] perf/x86/pebs: add workaround for broken OVFL status on HSW
Date: Wed, 14 Dec 2016 18:55:52 +0100 [thread overview]
Message-ID: <20161214175552.GW3207@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20160310104236.GV6344@twins.programming.kicks-ass.net>
Just spotted this again, ping?
On Thu, Mar 10, 2016 at 11:42:36AM +0100, Peter Zijlstra wrote:
> On Wed, Mar 09, 2016 at 09:40:07AM -0800, Stephane Eranian wrote:
> > With your queue.tip perf/core branch, I run into another problem.
> > I am monitoring with 2 PEBS events and I have the NMI watchdog enabled.
> >
> > I see non-EXACT PEBS records again, despite my change (which is in).
> > I tracked it down to the following issue after the testing of bit 62:
> >
> > [31137.273061] CPU71 status=0x200000001 orig_status=0x200000001 bit62=0
> >
> > The IRQ handler is called because the fixed counter for the NMI has overflowed
> > and it sees this in bit 33, but it also sees that one of the PEBS
> > events has also
> > overflowed, yet bit 62 is not set. Therefore both overflows are
> > treated as regular
> > and the drain_pebs() is not called generating a non-EXACT record for the PEBS
> > counter (counter 0). So something is wrong still and this is on Broadwell.
> >
> > First, I don't understand why the OVF bit for counter 0 is set. It
> > should not according
> > to specs because the counter is in PEBS mode. There must be a race there. So we
> > have to handle it by relying on cpuc->pebs_enabled. I will try that.
> > We likely also
> > need to force OVF bit 62 to 1 so we can ack it in the end (and in case
> > it gets set).
>
> How about we make the clear of pebs_enabled unconditional?
>
> ---
> arch/x86/events/intel/core.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 68fa55b4d42e..dc9579665425 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -1883,6 +1883,16 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
> status &= ~(GLOBAL_STATUS_COND_CHG |
> GLOBAL_STATUS_ASIF |
> GLOBAL_STATUS_LBRS_FROZEN);
> + /*
> + * There are cases where, even though, the PEBS ovfl bit is set
> + * in GLOBAL_OVF_STATUS, the PEBS events may also have their
> + * overflow bits set for their counters. We must clear them
> + * here because they have been processed as exact samples in
> + * the drain_pebs() routine. They must not be processed again
> + * in the for_each_bit_set() loop for regular samples below.
> + */
> + status &= ~cpuc->pebs_enabled;
> +
> if (!status)
> goto done;
>
> @@ -1892,16 +1902,6 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
> if (__test_and_clear_bit(62, (unsigned long *)&status)) {
> handled++;
> x86_pmu.drain_pebs(regs);
> - /*
> - * There are cases where, even though, the PEBS ovfl bit is set
> - * in GLOBAL_OVF_STATUS, the PEBS events may also have their
> - * overflow bits set for their counters. We must clear them
> - * here because they have been processed as exact samples in
> - * the drain_pebs() routine. They must not be processed again
> - * in the for_each_bit_set() loop for regular samples below.
> - */
> - status &= ~cpuc->pebs_enabled;
> - status &= x86_pmu.intel_ctrl | GLOBAL_STATUS_TRACE_TOPAPMI;
> }
>
> /*
next prev parent reply other threads:[~2016-12-14 17:56 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-03 19:50 [PATCH 0/3] perf/x86/pebs: various important fixes for PEBS Stephane Eranian
2016-03-03 19:50 ` [PATCH 1/3] perf/x86/intel: add definition for PT PMI bit Stephane Eranian
2016-03-08 13:16 ` [tip:perf/core] perf/x86/intel: Add " tip-bot for Stephane Eranian
2016-03-03 19:50 ` [PATCH 2/3] perf/x86/pebs: add workaround for broken OVFL status on HSW Stephane Eranian
2016-03-03 21:43 ` Andi Kleen
2016-03-03 23:40 ` Stephane Eranian
2016-03-07 10:24 ` Peter Zijlstra
2016-03-07 12:18 ` Peter Zijlstra
2016-03-07 18:27 ` Jiri Olsa
2016-03-07 20:25 ` Peter Zijlstra
2016-03-08 20:59 ` Stephane Eranian
2016-03-08 21:07 ` Peter Zijlstra
2016-03-08 21:13 ` Stephane Eranian
2016-03-09 5:34 ` Stephane Eranian
2016-03-09 5:44 ` Stephane Eranian
2016-03-09 17:40 ` Stephane Eranian
2016-03-10 10:42 ` Peter Zijlstra
2016-12-14 17:55 ` Peter Zijlstra [this message]
2016-12-15 7:26 ` Stephane Eranian
2016-12-15 7:52 ` Jiri Olsa
2016-12-15 8:04 ` Stephane Eranian
2016-12-15 8:42 ` Peter Zijlstra
2016-12-15 16:59 ` Stephane Eranian
2016-12-15 17:10 ` Peter Zijlstra
2016-12-16 8:38 ` Stephane Eranian
2016-12-16 17:48 ` Stephane Eranian
2016-03-10 13:53 ` Peter Zijlstra
2016-03-10 16:10 ` Stephane Eranian
2016-03-08 13:16 ` [tip:perf/core] perf/x86/pebs: Add workaround for broken OVFL status on HSW+ tip-bot for Stephane Eranian
2016-03-03 19:50 ` [PATCH 3/3] perf/x86/pebs: add proper PEBS constraints for Broadwell Stephane Eranian
2016-03-08 13:16 ` [tip:perf/core] perf/x86/pebs: Add " tip-bot for Stephane Eranian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161214175552.GW3207@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=namhyung@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.