All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Richter <robert.richter@amd.com>
To: Stephane Eranian <eranian@google.com>
Cc: Don Zickus <dzickus@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@elte.hu" <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 4/4] [x86] perf: fix accidentally ack'ing a second event on intel perf counter
Date: Thu, 2 Sep 2010 15:11:12 +0200	[thread overview]
Message-ID: <20100902131112.GR22783@erda.amd.com> (raw)
In-Reply-To: <AANLkTikOaCL8FqQuUQsYPxm19WZOdarp8AMAugN0mnqQ@mail.gmail.com>

On 02.09.10 04:13:19, Stephane Eranian wrote:
> Robert,
> 
> Do you have the test program you used to test this?
> I believe the NHM hack does not solve the problem, it
> just makes it harder to appear.

For testing back-to-back nmis I have used:

 perf record -e cycles -e instructions -e cache-references
       -e cache-misses -e branch-misses -a -- sleep 10

with load on all cpus. But I couldn't reproduce this particular
problem as I do not have such a system available. I think it might
trigger also with only one counter running. What the observed from the
status bits, only one counter was involved.

> 
> I suspect the real issue is that the GLOBAL_STATUS
> bitmask cannot be trusted. I'd like to verify this.

So yes, it looks like it is a cpu bug with a race then clearing the
status. I didn't check the errata list, maybe it is already known.

> 
> Has the problem appear only on Nehalem or also on
> Westmere?

I don't know.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center


  reply	other threads:[~2010-09-02 13:16 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 [this message]
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
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=20100902131112.GR22783@erda.amd.com \
    --to=robert.richter@amd.com \
    --cc=dzickus@redhat.com \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.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.