From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751444AbdFFRMk (ORCPT ); Tue, 6 Jun 2017 13:12:40 -0400 Received: from mga07.intel.com ([134.134.136.100]:49164 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751200AbdFFRMj (ORCPT ); Tue, 6 Jun 2017 13:12:39 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,306,1493708400"; d="scan'208";a="270895086" Date: Tue, 6 Jun 2017 10:12:37 -0700 From: Andi Kleen To: Peter Zijlstra Cc: Andi Kleen , acme@kernel.org, linux-kernel@vger.kernel.org, jolsa@kernel.org, Stephane Eranian Subject: Re: [PATCH 2/6] perf/x86: Fix data source decoding for Skylake Message-ID: <20170606171237.GC30867@tassilo.jf.intel.com> References: <20170605224838.11759-1-andi@firstfloor.org> <20170605224838.11759-2-andi@firstfloor.org> <20170606100822.fds5qmgimz74jfja@hirez.programming.kicks-ass.net> <20170606135120.GG8096@two.firstfloor.org> <20170606162108.2vdepfejvqrr7xpl@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170606162108.2vdepfejvqrr7xpl@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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