All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.