From: Stephane Eranian <eranian@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org, paulus@samba.org,
robert.richter@amd.com, fweisbec@gmail.com,
Arnaldo Carvalho de Melo <acme@infradead.org>
Subject: Re: [PATCH 3/5] perf, x86: Disable PEBS on clowertown chips
Date: Fri, 5 Mar 2010 13:57:49 -0800 [thread overview]
Message-ID: <bd4cb8901003051357o357ac7adt7cb56b5deb4089dd@mail.gmail.com> (raw)
In-Reply-To: <1267825433.4997.14.camel@laptop>
On Fri, Mar 5, 2010 at 1:43 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2010-03-05 at 13:38 -0800, Stephane Eranian wrote:
>> On Fri, Mar 5, 2010 at 1:35 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Fri, 2010-03-05 at 13:22 -0800, Stephane Eranian wrote:
>> >> > The two serious ones, AJ106 and AJ68 are no fix and are listed as such
>> >> > in all errata I can find, including the 7[23]00 series.
>> >> >
>> >> Not E74xx. I think it would be fine to drop LBR with PEBS as the work-around
>> >> to AJ106.
>> >>
>> >> > I checked the 65nm Core2Duo, Xeon 5200 and Xeon 7[23]00 spec updates.
>> >> > Going by that it seems the full model 15 family is broken and I'll leave
>> >> > the patch as is.
>> >>
>> >> But the E74xx are okay and you are excluding them. Worst case you should
>> >> provide an override.
>> >
>> > >From what I can tell E74xx is model 29, which would be just fine with
>> > this patch, this patch only marks model 15 as broken.
>> >
>> True, my bad.
>> So it would be a matter to provide some ways of disabling LBR with PEBS
>> on model 15.
>
> And some way of dealing with the flaky PEBS PMI, which requires we
> program the pebs_event_reset thing otherwise there won't be a next PEBS
> record to re-trigger the PMI.
>
> If it would have stated it always did the threshold comparison first and
> then the index increment, so that we'd always trigger on the second
> record we could simply program half the period and always take two and
> ignore the first, but it says _MAY_, so its a race and there's no
> reliable solution.
>
> It might all be possible but I don't see it being worth the effort.
>
There are lots of model15 out there, like the Q6xxx series.
When I read AJ68, my understanding is that it's not that you do not
get the interrupt. It will be delayed by one event. The buffer will become
full. You won't overrun the buffer, you will get the interrupt at the next
event. On interrupt, you have to reset the PEBS position pointer anyway.
There is already a disconnect between the sampling period and the actual
instruction sampled. That's not making the situation that much worse, unless
I am missing something.
next prev parent reply other threads:[~2010-03-05 21:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-05 15:39 [PATCH 0/5] PEBS and LBR fixes Peter Zijlstra
2010-03-05 15:39 ` [PATCH 1/5] perf: Rework the arch CPU-hotplug hooks Peter Zijlstra
2010-03-10 13:10 ` [tip:perf/urgent] perf: Rework and fix " tip-bot for Peter Zijlstra
2010-03-05 15:39 ` [PATCH 2/5] perf, x86: Fix silly bug in data store buffer allocation Peter Zijlstra
2010-03-10 13:20 ` [tip:perf/pebs] " tip-bot for Peter Zijlstra
2010-03-05 15:39 ` [PATCH 3/5] perf, x86: Disable PEBS on clowertown chips Peter Zijlstra
2010-03-05 18:58 ` Stephane Eranian
2010-03-05 19:15 ` Peter Zijlstra
2010-03-05 19:28 ` Stephane Eranian
2010-03-05 19:37 ` Peter Zijlstra
2010-03-05 21:05 ` Peter Zijlstra
2010-03-05 21:22 ` Stephane Eranian
2010-03-05 21:35 ` Peter Zijlstra
2010-03-05 21:38 ` Stephane Eranian
2010-03-05 21:43 ` Peter Zijlstra
2010-03-05 21:57 ` Stephane Eranian [this message]
2010-03-05 22:25 ` Peter Zijlstra
2010-03-05 22:33 ` Stephane Eranian
2010-03-10 13:21 ` [tip:perf/pebs] perf, x86: Disable PEBS on clovertown chips tip-bot for Peter Zijlstra
2010-03-05 15:39 ` [PATCH 4/5] perf, x86: Clear the LBRs on init Peter Zijlstra
2010-03-10 13:21 ` [tip:perf/pebs] " tip-bot for Peter Zijlstra
2010-03-05 15:39 ` [PATCH 5/5] perf, x86: Robustify PEBS fixup Peter Zijlstra
2010-03-10 13:21 ` [tip:perf/pebs] " tip-bot for Peter Zijlstra
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=bd4cb8901003051357o357ac7adt7cb56b5deb4089dd@mail.gmail.com \
--to=eranian@google.com \
--cc=acme@infradead.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®