Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 2 Aug 2018 21:54:10 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     Reinette Chatre <reinette.chatre@intel.com>, tglx@linutronix.de,
        mingo@redhat.com, fenghua.yu@intel.com, tony.luck@intel.com,
        vikas.shivappa@linux.intel.com, gavin.hindman@intel.com,
        jithu.joseph@intel.com, hpa@zytor.com, x86@kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] x86/intel_rdt and perf/x86: Fix lack of coordination
 with perf
Message-ID: <20180802195410.GR2494@hirez.programming.kicks-ass.net>
References: <cover.1533064851.git.reinette.chatre@intel.com>
 <20180802123923.GJ2530@hirez.programming.kicks-ass.net>
 <1af731f8-b5d3-5aca-af02-575802a961b9@intel.com>
 <20180802161823.GJ2458@hirez.programming.kicks-ass.net>
 <f990df31-ab75-974e-b142-47af07a33a08@intel.com>
 <20180802173727.GP2494@hirez.programming.kicks-ass.net>
 <653e874f-5e77-a9b5-996a-ed9daa3c6d43@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <653e874f-5e77-a9b5-996a-ed9daa3c6d43@intel.com>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Aug 02, 2018 at 11:18:01AM -0700, Dave Hansen wrote:
> On 08/02/2018 10:37 AM, Peter Zijlstra wrote:
> >> I do not see how I can do so without incurring the cache hits and misses
> >> from the data needed and instructions run by this interface. Could you
> >> please share how I can do so and still obtain the accurate measurement
> >> of cache residency of a specific memory region?
> > That's the best you're going to get. You do _NOT_ get to use raw PMU.
> 
> Hi Peter,
> 
> This code is really fidgety.  It's really easily perturbed even by tiny
> things like implicit cache accesses from the page walker filling the TLB
> from the page tables.
> 
> Adding a bunch more code in the way is surely going to make it more
> fragile and imprecise.
> 
> I totally understand not wanting to fill the tree with code hijacking
> the raw PMU.  Is your reaction to this really around not wanting to
> start down the slippery slope that ends up with lots of raw PMU "owners"?

That and the fact that multiple owner directly contradicts what perf set
out to do, provide resource arbitration for the PMU.

Not being able to use both perf and this resctl thing at the same time
is utter crap. You will not get special dispensation.