Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp521052imm; Wed, 8 Aug 2018 00:42:32 -0700 (PDT) X-Google-Smtp-Source: AA+uWPz0W2nBCSax++6mzgcibkXCi5QSvlVe0XYdK3wQ5B8Gn8E7SX9TIV54j20s2J5tOJ6BiyVm X-Received: by 2002:a63:5a5e:: with SMTP id k30-v6mr1470927pgm.123.1533714152258; Wed, 08 Aug 2018 00:42:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533714152; cv=none; d=google.com; s=arc-20160816; b=RqpHtVKM/5WgIR216K5zML63JdRh4k6mdP3Vi2sbj/X3tsN5K1Fn1vg5f1C8oaLd/p zMkA7qsUZkC3raM+Zc8F58FAWkPrXR7kzrxPZCqwfmd5FWrt97+1LJQRbPkyZQgtfF72 UEUy+BoFRg0dkHKR4VZ7M55MVwwTasAFTRPMrBDGrLQjVyC2q6+4hpctzYd46pE+NnCC 5ba9lvmvMO2951Jdsh/kAn8Gwj1eRJMn5B3qqe0JeHG8Nqyc67geUnTPqkXQN/4qtRKH IN3BtHFOYsDdiANQxWUDN5waiNdlX3T5FSVxGFv54O0EnWiqOk60TRO9ioTrgLDXKtmP mGMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=np/8aWXAd73bWdcLxs5j43KSI44vz6tqP9Cu98hgRao=; b=Qe/7k6yQsmxCBP6ZBuenU65agRwz/OTpedESrkrX5wA5Rivm0GGOBJqeiBM3L6so6K LWYkFTSBRoS63w+8OlNAQVpw5Fi6KT543mku8HH4A0uqItfyRPxgEUhp0ZIVqjtSBhIe RqSfh34fQjicSc1iHrzV1twYsuFfItFYWF0ipHC2t/xFOaksq3OGKURU1Y7y52RnWcz6 LoX5OypjF4U3l+KC7D/fDNIPQJOSD+d2NwMkcnnUo12850P8ZhYy4aPpgVKaaded1y2q oC1N4jcvI81ntkNvOgtvY2637EmdNnAX2HsoERqOxt+Ir3aUfAkmrHkoFxToBezaYc0R R66A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=rugzuwPP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t8-v6si3215979pgl.620.2018.08.08.00.42.17; Wed, 08 Aug 2018 00:42:32 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=rugzuwPP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727050AbeHHJ7o (ORCPT + 99 others); Wed, 8 Aug 2018 05:59:44 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:34550 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726721AbeHHJ7n (ORCPT ); Wed, 8 Aug 2018 05:59:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=np/8aWXAd73bWdcLxs5j43KSI44vz6tqP9Cu98hgRao=; b=rugzuwPPDFDcLN1G06CPkITvz NnFCy8vAqBnEWmQLEWhYNz6rzi6cRUksz7zisTbXGlNyu2g0pT2djVrd4APduXnvjWo/0VMM/pNM2 6WxhcJy+cFjUlr9ywQ6WiSkbnWbvNkQ6N1fICu/Y5IObu+y/SBposmjl2Ie2Q5GGhTLf7cREMo5z5 kTJEXDxF+765HROXImUee2LYfBXQZjAG3evD0/ZPWkfeE1pmd3yKydiwgctqZV3tsZDk7ZI/VYKgA Sic4ltdsf6QN2V5TBWeOXcY9nEID43StLvbTxbetpjyV5ITqyC+EhGFtdXFsTuPdWLEdYzFN2u2h6 no0KbOcdw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fnJ5m-0004Zn-Jq; Wed, 08 Aug 2018 07:41:14 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 2FE8620163EC0; Wed, 8 Aug 2018 09:41:11 +0200 (CEST) Date: Wed, 8 Aug 2018 09:41:11 +0200 From: Peter Zijlstra To: Reinette Chatre Cc: "Luck, Tony" , "Hansen, Dave" , "tglx@linutronix.de" , "mingo@redhat.com" , "Yu, Fenghua" , "vikas.shivappa@linux.intel.com" , "Hindman, Gavin" , "Joseph, Jithu" , "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: <20180808074111.GM2494@hirez.programming.kicks-ass.net> References: <1eece033-fbae-c904-13ad-1904be91c049@intel.com> <20180803152523.GY2476@hirez.programming.kicks-ass.net> <57c011e1-113d-c38f-c318-defbad085843@intel.com> <20180806221225.GO2458@hirez.programming.kicks-ass.net> <08d51131-7802-5bfe-2cae-d116807183d1@intel.com> <20180807093615.GY2494@hirez.programming.kicks-ass.net> <3908561D78D1C84285E8C5FCA982C28F7D3A10EF@ORSMSX110.amr.corp.intel.com> <413c3b6f-770d-9549-4249-c2407267b63c@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413c3b6f-770d-9549-4249-c2407267b63c@intel.com> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 07, 2018 at 10:44:44PM -0700, Reinette Chatre wrote: > Hi Tony, > > On 8/7/2018 6:28 PM, Luck, Tony wrote: > > Would it help to call routines to read the "before" values of the counter > > twice. The first time to preload the cache with anything needed to execute > > the perf code path. Indeed, that is the 'common' pattern for this. > First, reading data using perf_event_read_local() called twice. > When testing as follows: > /* create perf events */ > /* disable irq */ > /* disable hw prefetchers */ > /* init local vars */ > /* read before data twice as follows: */ > perf_event_read_local(l2_hit_event, &l2_hits_before, NULL, NULL); > perf_event_read_local(l2_miss_event, &l2_miss_before, NULL, NULL); > perf_event_read_local(l2_hit_event, &l2_hits_before, NULL, NULL); > perf_event_read_local(l2_miss_event, &l2_miss_before, NULL, NULL); > /* read through pseudo-locked memory */ > perf_event_read_local(l2_hit_event, &l2_hits_after, NULL, NULL); > perf_event_read_local(l2_miss_event, &l2_miss_after, NULL, NULL); > /* re enable hw prefetchers */ > /* enable irq */ > /* write data to tracepoint */ > > With the above I am not able to obtain accurate data: > pseudo_lock_mea-354 [002] .... 63.045734: pseudo_lock_l2: hits=4103 > miss=6 So _why_ doesn't this work? As said by Tony, that first call should prime the caches, so the second and third calls should not generate any misses. They might cause extra hits though, but that should be a constant amount is is also measureable with a no-op loop and can easily be subtracted.