[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140731074938.GX9918@twins.programming.kicks-ass.net>
Date: Thu, 31 Jul 2014 09:49:38 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Yan, Zheng" <zheng.z.yan@...el.com>
Cc: linux-kernel@...r.kernel.org, mingo@...nel.org, acme@...radead.org,
eranian@...gle.com, andi@...stfloor.org
Subject: Re: [PATCH v4 0/9] perf, x86: large PEBS interrupt threshold
On Thu, Jul 31, 2014 at 03:36:26PM +0800, Yan, Zheng wrote:
> On 07/31/2014 03:27 PM, Peter Zijlstra wrote:
> >
> >
> > OK, so no feedback on the 'pending' discussions we had wrt PEBS record
> > generation?
> >
> > No feedback on the correctness aspects of the overflow crap?
> >
> > Just a new series, which I then have to dig through to figure out wtf
> > changed?
> >
> > A quick look at patch 6 reads like you still don't understand the issue
> > right. There are no 'collisions' as such in PEBS record generation, or
> > are there? See the earlier open discussion.
>
> I'm sure collision only create one PEBS records. Actually, the patch description
> was written by Andi.
So now Andi is contradicting himself:
http://marc.info/?l=linux-kernel&m=140129731708247&w=2
Bloody wonderful..
OK, so someone write down exactly how PEBS record generation works,
including the iffy overflow register, bring it to the relevant hardware
engineer, having him sign off on it, then come back.
And preferably add it to the next SDM rev. How is anybody to use this
stuff without knowing how it works?!
Let me try and figure out if actual collisions mean we cannot
reconstruct the actual events or not, you do the same.
Please file an internal bug report against that hardware (if there isn't
one already -- I've only been asking for this to get fixed for years
now).
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists