From: Don Zickus <dzickus@redhat.com>
To: Stephane Eranian <eranian@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Robert Richter <robert.richter@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@elte.hu" <mingo@elte.hu>
Subject: Re: [PATCH 4/4] [x86] perf: fix accidentally ack'ing a second event on intel perf counter
Date: Fri, 3 Sep 2010 10:03:30 -0400 [thread overview]
Message-ID: <20100903140330.GW4879@redhat.com> (raw)
In-Reply-To: <AANLkTimyk1PvCBQzqcmcqL7HetXso=_akKvrUM0+hOoD@mail.gmail.com>
On Fri, Sep 03, 2010 at 01:02:49PM +0200, Stephane Eranian wrote:
> Here is an example of what I gathered on a Westmere:
>
> This is coming into the interrupt handler:
> - status = overflow status coming from GLOBAL_OVF_STATUS
> - status2 = inspection of the counters
> - act = cpuc->active_mask[0]
>
> In case both status don't match, I dump the state of the active events
> incl. the counter values(val).
>
> [ 822.813808] CPU2 irqin status=0x6 status2=0x4 act=0x7
> [ 822.813818] CPU2 cfg=0x13003c idx=0 sel=53003c val=ffffa833f298
> [ 822.813821] CPU2 cfg=0x12003c idx=1 sel=52003c val=fffffe130229
> [ 822.813823] CPU2 cfg=0x11003c idx=2 sel=51003c val=5e9
>
> Here only counter2 has overflowed, yet the handler will also process counter1
> which is wrong.
Hmm, the test case I used was 'perf top'. This was only using perf
counter0. So I am not sure, at least in my case, it was a stale event.
Though I don't think I remember checking the status immediately after
acking it just to verify the ack worked.
I'll poke some more on my machine today.
Cheers,
Don
next prev parent reply other threads:[~2010-09-03 14:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-01 13:04 [PATCH 4/4] [x86] perf: fix accidentally ack'ing a second event on intel perf counter Stephane Eranian
2010-09-01 14:57 ` Robert Richter
2010-09-02 8:13 ` Stephane Eranian
2010-09-02 13:11 ` Robert Richter
2010-09-02 14:19 ` Don Zickus
2010-09-02 14:39 ` Stephane Eranian
2010-09-02 15:47 ` Don Zickus
2010-09-02 16:18 ` Stephane Eranian
2010-09-03 8:33 ` Peter Zijlstra
2010-09-03 11:02 ` Stephane Eranian
2010-09-03 11:11 ` Peter Zijlstra
2010-09-03 11:52 ` Stephane Eranian
2010-09-03 14:03 ` Don Zickus [this message]
2010-09-03 14:28 ` Stephane Eranian
-- strict thread matches above, loose matches on Subject: below --
2010-09-01 2:56 [PATCH 0/4] nmi perf fixes Don Zickus
2010-09-01 2:56 ` [PATCH 4/4] [x86] perf: fix accidentally ack'ing a second event on intel perf counter Don Zickus
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=20100903140330.GW4879@redhat.com \
--to=dzickus@redhat.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
/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.