lkml.org 
[lkml]   [2017]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/6] perf/x86: Fix data source decoding for Skylake
On Tue, Jun 06, 2017 at 06:21:08PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2017 at 06:51:20AM -0700, Andi Kleen wrote:
> > > Not too happy about that..
> > >
> > > P(LVLX, L4) | P(LVLX, REMOTE)
> > >
> > > reads like something that should be PERF_MEM_LVL_REM_CCE1 or something
> >
> > CCE1? You mean L4?
>
> #define PERF_MEM_LVL_REM_CCE1 0x400 /* Remote Cache (1 hop) */
>
> It says 'cache' which is irrespective of level.

But remote L4 is far more useful than remote something.

(even though it currently doesn't exist, so it's not too important)

>
> > The two bits seem cleaner to me than enumerating all cases. But ok.
>
> I tend to agree that a separate remote,distance,type fields would have
> been nicer, but we seem to be stuck with this REM_* crud..

Obviously the old ones cannot be changed, but I don't see any reason
not to do better for new encodings.

>
> > > This new generic 'REMOTE' has too much overlap with the existing things.
> >
> > So you want a REM_NA ?
>
> Not sure... What's the point of a REM_NA vs regular NA ? "'something'
> happened 'not here'" vs "'something' happened".

It's a very big difference in latency. That's useful information.

> I hope Stephane has better ideas, he seems to be the one that introduced
> this in the first place.

The original bits were pretty much a direct mapping from the Nehalem
Intel bits. But even Intel has out grown it to some degree.

-Andi

\
 
 \ /
  Last update: 2017-06-12 00:50    [W:0.045 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site