From: Ingo Molnar <mingo@kernel.org>
To: eranian@gmail.com
Cc: Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: PEBS bug on HSW: "Unexpected number of pebs records 10" (was: Re: [GIT PULL] perf changes for v3.12)
Date: Tue, 10 Sep 2013 16:29:43 +0200 [thread overview]
Message-ID: <20130910142942.GB8388@gmail.com> (raw)
In-Reply-To: <CAMsRxfJ5HG+0AiooOUFh8TzvCoK3YcBFpeAF0eTzdkDm=wB84g@mail.gmail.com>
* Stephane Eranian <eranian@googlemail.com> wrote:
> On Tue, Sep 10, 2013 at 6:38 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Stephane Eranian <eranian@googlemail.com> wrote:
> >
> >> Hi,
> >>
> >> Ok, so I am able to reproduce the problem using a simpler
> >> test case with a simple multithreaded program where
> >> #threads >> #CPUs.
> >
> > Does it go away if you use 'perf record --all-cpus'?
> >
> Haven't tried that yet.
>
> But I verified the DS pointers:
> init:
> CPU6 pebs base=ffff8808262de000 index=ffff8808262de000
> intr=ffff8808262de0c0 max=ffff8808262defc0
> crash:
> CPU6 pebs base=ffff8808262de000 index=ffff8808262de9c0
> intr=ffff8808262de0c0 max=ffff8808262defc0
>
> Neither the base nor the max are modified.
> The index simply goes beyond the threshold but that's not a bug.
> It is 12 after the threshold of 1, so total 13 is my new crash report.
>
> Two things to try:
> - measure only one thread/core
> - move the threshold a bit farther away (to get 2 or 3 entries)
>
> The threshold is where to generate the interrupt. It does not mean where
> to stop PEBS recording. So it is possible that in HSW, we may get into a
> situation where it takes time to get to the handler to stop the PMU. I
> don't know how given we use NMI. Well, unless we were already servicing
> an NMI at the time. But given that we stop the PMU almost immediately in
> the handler, I don't see how that would possible. The other oddity in
> HSW is that we clear the NMI on entry to the handler and not at the end.
> I never gotten an good explanation as to why that was necessary. So
> maybe it is related...
Do you mean:
if (!x86_pmu.late_ack)
apic_write(APIC_LVTPC, APIC_DM_NMI);
AFAICS that means the opposite: that we clear the NMI late, i.e. shortly
before return, after we've processed the PMU.
Do the symptoms change if you remove the x86_pmu.late_ack setting line
from:
case 60: /* Haswell Client */
case 70:
case 71:
case 63:
case 69:
x86_pmu.late_ack = true;
?
Thanks,
Ingo
next prev parent reply other threads:[~2013-09-10 14:29 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-03 13:29 [GIT PULL] perf changes for v3.12 Ingo Molnar
2013-09-03 13:37 ` Arnaldo Carvalho de Melo
2013-09-03 13:43 ` Ingo Molnar
2013-09-03 17:02 ` Vince Weaver
2013-09-04 17:53 ` Linus Torvalds
2013-09-05 10:56 ` Ingo Molnar
2013-09-05 12:42 ` Frederic Weisbecker
2013-09-05 12:51 ` Ingo Molnar
2013-09-05 12:58 ` Frederic Weisbecker
2013-09-10 8:06 ` Namhyung Kim
2013-09-10 11:18 ` Frederic Weisbecker
2013-09-05 13:38 ` Ingo Molnar
2013-09-08 2:17 ` Linus Torvalds
2013-09-09 10:05 ` Peter Zijlstra
2013-09-10 11:28 ` Stephane Eranian
2013-09-10 11:53 ` PEBS bug on HSW: "Unexpected number of pebs records 10" (was: Re: [GIT PULL] perf changes for v3.12) Ingo Molnar
2013-09-10 12:32 ` Stephane Eranian
2013-09-10 12:42 ` Ramkumar Ramachandra
2013-09-10 12:51 ` Ramkumar Ramachandra
2013-09-10 12:55 ` Stephane Eranian
2013-09-10 13:22 ` Ingo Molnar
2013-09-10 13:38 ` Ingo Molnar
2013-09-10 14:15 ` Stephane Eranian
2013-09-10 14:29 ` Ingo Molnar [this message]
2013-09-10 14:34 ` Stephane Eranian
2013-09-10 17:14 ` Ingo Molnar
2013-09-16 11:07 ` Stephane Eranian
2013-09-16 15:41 ` Ingo Molnar
2013-09-16 16:29 ` Peter Zijlstra
2013-09-17 7:00 ` Ingo Molnar
2013-09-23 15:25 ` Stephane Eranian
2013-09-23 15:33 ` Peter Zijlstra
2013-09-23 17:11 ` Stephane Eranian
2013-09-23 17:24 ` Peter Zijlstra
2013-09-10 15:28 ` Peter Zijlstra
2013-09-10 16:14 ` 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=20130910142942.GB8388@gmail.com \
--to=mingo@kernel.org \
--cc=acme@infradead.org \
--cc=andi@firstfloor.org \
--cc=eranian@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.