From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C0431C4829E for ; Thu, 15 Feb 2024 07:09:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BaF+XEuwNFaHedNZ2l0s9+AvXK2dLk8Wd6rwnwIOXTw=; b=ps9mR4MnrMtqoC RCFgfjeiJsYcuvOX4PukcJiEUH0A/5tjfRJY0kKrVWQ/S8E3MJRFiM6NzhBKVPpP5on63edIc0doT cs0bLnWpUkoVuahG039vx6miZQlLJZNJ7BV3vQep34MOtPSeK1ZYyTsh5dOieQQyMKdLADkeu2Dhu BVytagwQ7eMZjk+FAzYGFLocgLrdoAkQswAsqBJLnHJJM6hp7jP0nKJVzlEUoEBKeXFrFcwTkR5ep BnfXzcX7Kby932hsvz6KT9k/kCZT3zg1YLuV0xYYvFPqDaggWAxtfvuuHFZmiFzt1VSw61uBd1e6J ktz620Dxwwc+6MwTcyBA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1raVrY-0000000FCL8-32Xx; Thu, 15 Feb 2024 07:08:52 +0000 Received: from mgamail.intel.com ([198.175.65.19]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1raVrV-0000000FCKO-3nxs for linux-arm-kernel@lists.infradead.org; Thu, 15 Feb 2024 07:08:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1707980930; x=1739516930; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=IrFzdD8XFZTzKPegTy0YzhPFfPW8Y+EoXkVTZvyKbFc=; b=Od9UxVSaVJLBQcr9vM88Ju48HkA9Ti73TFD2ZgJ3+5Y4cCp12D0FrPMj pJmG9TZvVQfa3Ov/gHMFy77Nm27+zThI3myxR7zhHeH2RJgPu26++MTLj spYxIAgOgOA+4MGsKqs7KC3gzF7T0aYDlEgO76vllH3pUa7satl5Cp8+5 2jiavTDqxw9Typb01xIDtrftdI+k+HOz/NtH2eqdbj/L9WfglqO01Bq1r LTXpbfLic0dtzUtCJfH5Jk6vdD2/2eO2FgO0g9TTePtnS6Za6jm19iqj2 Au/PZ9+AwFw/ocTTWt53irkpP3c5pasHAGXwmZm3m9/0nSOLml77Eevwi A==; X-IronPort-AV: E=McAfee;i="6600,9927,10984"; a="1910967" X-IronPort-AV: E=Sophos;i="6.06,161,1705392000"; d="scan'208";a="1910967" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2024 23:08:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,161,1705392000"; d="scan'208";a="3426313" Received: from tassilo.jf.intel.com (HELO tassilo) ([10.54.38.190]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2024 23:08:46 -0800 Date: Wed, 14 Feb 2024 23:08:40 -0800 From: Andi Kleen To: Ben Gainey Cc: "irogers@google.com" , "alexander.shishkin@linux.intel.com" , "peterz@infradead.org" , Mark Rutland , "linux-perf-users@vger.kernel.org" , "mingo@redhat.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "jolsa@kernel.org" , "acme@kernel.org" , "namhyung@kernel.org" , "adrian.hunter@intel.com" , "will@kernel.org" Subject: Re: [RFC PATCH 0/2] A mechanism for efficient support for per-function metrics Message-ID: References: <20240123113420.1928154-1-ben.gainey@arm.com> <87r0hfwet0.fsf@linux.intel.com> <7de25cbdc9df21e1723d209ca8bd377a55bb54e4.camel@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <7de25cbdc9df21e1723d209ca8bd377a55bb54e4.camel@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240214_230850_022434_46043517 X-CRM114-Status: GOOD ( 45.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Feb 14, 2024 at 07:13:50PM +0000, Ben Gainey wrote: > > Nice, I wasn't aware of this feature. I'll have a play... You have to use an old perf version for now, still need to fix it. > > > > > > Of course the feature is somewhat dubious in that it will have a very > > strong systematic bias against short functions and even long > > functions > > in some alternating execution patterns. I assume you did some > > experiments to characterize this. It would be important > > to emphasize this in any documentation. > > The way I have been thinking about this is that for each sample you > always maintain a periodic sample count so that the relative ranking of > functions is maintained, and that the "same as previous" check is a way > to enhance the attributability of the PMU data for any given sample. > > But it absolutely correct to say that this will bias the availability > of PMU data in the way you have describe. The bias depends on sample > window size, workload characteristics and so on. I would be more comfortable with it if you added some randomization on the window sizes. That would limit bias and worst case sampling error. > It should be possible to provide a per metric "valid sample" count that > can be used to judge the "quality" of the metrics for each symbol, > which may allow the user to make some adjustments to the recording > paramters (modify sample period, or sample window size for example). Even that would be misleading because it assumes that the IP stayed in the same function between the two samples. But you could have something like F1 sample F2 F1 sample and if you're unlucky this could happen systematically. The randomization would fight it somewhat, but even there you might be very very unlucky. The only sure way to judge it really is to run branch trace in parallel and see if it is correct. Also there is of course the problem that on a modern core the reordering window might well be larger than your sample window, so any notion of things happening inside a short window is quite fuzzy. > > > > I don't see anything ARM specific with the technique, so if it's done > > it should be done generically IMHO > > > Great. When i was originally thinking about the implementation of the > event strobing feature I was thinking: > > * Add `strobe_sample` flag bit to opt into the fature > - This will be mutually exclusive with `freq`. > * Add `strobe_period` field to hold the alternate sample period (for > the sample window. > * Have all PMU drivers check and reject the `strobe_sample` flag by > default; the swizzling of the period will be done in the PMU driver its > self if it make sense to support this feature for a given PMU. > - Do you think this is sensible, or would be better handled in core? I would have a common function in core that is called from the PMU drivers, similar to how the adaptive period is done today. > > > the patch) suggests this approach would work for some counters. > > > Calculating branch miss rates for example appears to be correct, > > > likewise UOPS_EXECUTED.THREAD seems to give something like a > > > sensible > > > cycles-per-uop value. On the other hand the fixed function > > > instructions > > > counter does not appear to sample correctly (it seems to report > > > either > > > very small or very large numbers). No idea whats going on there, so > > > any > > > insight welcome... > > > > If you use precise samples with 3p there is a restriction on the > > periods > > that is enforced by the kernel. Non precise or single/double p should > > support arbitrary, except that any p is always period + 1. > > Is there some default value for precise? when testing I didn't set any > specific value for p modifier. In some cases the perf tool tries to use the highest, e.g. if you don't specify anything. If you used :p (and not :P) it should have taken the number you specified. Single :p is normally not useful because it samples the -1 IP, normal use is either two or three p. Three p is more precise but also has some restrictions on the sampling period and the counters that can be used. -Andi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel