From: Andi Kleen <ak@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andi Kleen <andi@firstfloor.org>,
acme@kernel.org, linux-kernel@vger.kernel.org, jolsa@kernel.org,
Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH 2/6] perf/x86: Fix data source decoding for Skylake
Date: Tue, 6 Jun 2017 10:12:37 -0700 [thread overview]
Message-ID: <20170606171237.GC30867@tassilo.jf.intel.com> (raw)
In-Reply-To: <20170606162108.2vdepfejvqrr7xpl@hirez.programming.kicks-ass.net>
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
next prev parent reply other threads:[~2017-06-06 17:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-05 22:48 [PATCH 1/6] perf/x86: Move Nehalem PEBS code to flag Andi Kleen
2017-06-05 22:48 ` [PATCH 2/6] perf/x86: Fix data source decoding for Skylake Andi Kleen
2017-06-06 10:08 ` Peter Zijlstra
2017-06-06 13:51 ` Andi Kleen
2017-06-06 16:21 ` Peter Zijlstra
2017-06-06 17:12 ` Andi Kleen [this message]
2017-06-05 22:48 ` [PATCH 3/6] perf, tools: Add support for printing new mem_info encodings Andi Kleen
2017-06-05 22:48 ` [PATCH 4/6] perf/x86: Add support for PEBS sampling persistent RAM on Skylake Andi Kleen
2017-06-05 22:48 ` [PATCH 5/6] perf, tools: Support persistent memory encoding Andi Kleen
2017-06-05 22:48 ` [PATCH 6/6] perf, tools: Add test cases for new data source encoding Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2017-06-02 20:12 [PATCH 1/6] perf/x86: Move Nehalem PEBS code to flag Andi Kleen
2017-06-02 20:12 ` [PATCH 2/6] perf/x86: Fix data source decoding for Skylake Andi Kleen
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=20170606171237.GC30867@tassilo.jf.intel.com \
--to=ak@linux.intel.com \
--cc=acme@kernel.org \
--cc=andi@firstfloor.org \
--cc=eranian@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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.