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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 D8756C8303F for ; Wed, 27 Aug 2025 08:05:53 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4cBcXw3q9Lz3bV6; Wed, 27 Aug 2025 18:05:52 +1000 (AEST) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1756281952; cv=none; b=K58UhcDlR518VXlZWMcKHhvXOwSLLSJQMnkJk6zparhpc5jG0BsSOlf9hxj+k1IO0wF+XLhdzsna68rK5/V3ecQUEdRr/xXg6rzcFAlmik8Y/JxPMf1zAIzSymRqBLPIm8gl/BEYmTDjyW6n6gwS9XQD4SWHGyjPd3P6W/og3AGd237SLp72lpEe4sxI/NkgIUy5Gc0BSz46hGddfClXjYP4WcLxCN26sWEfa4MYR9VegfcoLd2uuq0hRFQ5QiKLAvWSHJYOw782n4WbpHGMPGLVMbkfg87p0mTOd6nqnlmIcaUTTfmGMJo3fXr+LxIPYxfgltCk623+EGD/0Ovd7w== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1756281952; c=relaxed/relaxed; bh=6196K8b9+MG5o4AtOQJKUUdlGUlbg/6yMa2kEgseBX0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oQ9ROmS0E+Pwxc0c/VjyQbPnqjhAoNRz/D6GOng/q/J+sZQmrKyfdry87FGZwp5S5FZB7KSqkU+zT3glsQuKEurZrKy+zXw2I9dxXtRpIUv/pQxs3nAUSEbhP/lF3dKh4zPdHAK/PTIWQJ3p1SNxI2UjU1UEQ84YSShjhzKiEy1aYpU/i86bvpD5VxL9wNIrYk84PocVS4KajjXkPtlXePq5WKkvxCaPE1p+ANgAd1BDV8q7lnl8kJYqtlleadhyAO9rQX5r4fOUB6hGjoc+BhJKpy9uJ+iO0M6S0tilE3QrAfnJWRBzT2qPFfTX+UJGiqJvaDbmQxKYgsbivkaNFQ== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass (client-ip=217.140.110.172; helo=foss.arm.com; envelope-from=mark.rutland@arm.com; receiver=lists.ozlabs.org) smtp.mailfrom=arm.com Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arm.com (client-ip=217.140.110.172; helo=foss.arm.com; envelope-from=mark.rutland@arm.com; receiver=lists.ozlabs.org) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lists.ozlabs.org (Postfix) with ESMTP id 4cBcXv3CMBz30WF for ; Wed, 27 Aug 2025 18:05:49 +1000 (AEST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3E3641691; Wed, 27 Aug 2025 01:05:09 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D650B3F694; Wed, 27 Aug 2025 01:05:07 -0700 (PDT) Date: Wed, 27 Aug 2025 09:04:46 +0100 From: Mark Rutland To: Robin Murphy Cc: peterz@infradead.org, mingo@redhat.com, will@kernel.org, acme@kernel.org, namhyung@kernel.org, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev, linux-csky@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-pm@vger.kernel.org, linux-rockchip@lists.infradead.org, dmaengine@vger.kernel.org, linux-fpga@vger.kernel.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, coresight@lists.linaro.org, iommu@lists.linux.dev, linux-amlogic@lists.infradead.org, linux-cxl@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH 18/19] perf: Introduce positive capability for raw events Message-ID: References: <542787fd188ea15ef41c53d557989c962ed44771.1755096883.git.robin.murphy@arm.com> <015974a4-f129-4ae5-adf9-c94b29f0576a@arm.com> X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015974a4-f129-4ae5-adf9-c94b29f0576a@arm.com> On Tue, Aug 26, 2025 at 11:46:02PM +0100, Robin Murphy wrote: > On 2025-08-26 2:43 pm, Mark Rutland wrote: > > On Wed, Aug 13, 2025 at 06:01:10PM +0100, Robin Murphy wrote: > > To bikeshed a little here, I'm not keen on the PERF_PMU_CAP_RAW_EVENTS > > name, because it's not clear what "RAW" really means, and people will > > definitely read that to mean something else. > > > > Could we go with something like PERF_PMU_CAP_COMMON_CPU_EVENTS, to make > > it clear that this is about opting into CPU-PMU specific event types (of > > which PERF_TYPE_RAW is one of)? > > Indeed I started with that very intention after our previous discussion, but > soon realised that in fact nowhere in the code is there any definition or > even established notion of what "common" means in this context, so it's > hardly immune to misinterpretation either. We can document that; it's everything less than PERF_TYPE_MAX: enum perf_type_id { PERF_TYPE_HARDWARE = 0, PERF_TYPE_SOFTWARE = 1, PERF_TYPE_TRACEPOINT = 2, PERF_TYPE_HW_CACHE = 3, PERF_TYPE_RAW = 4, PERF_TYPE_BREAKPOINT = 5, PERF_TYPE_MAX, /* non-ABI */ }; ... and maybe you could use "PERF_PMU_CAP_ABI_TYPES" to align with that comment? > Furthermore the semantics of the cap as it ended up are specifically > that the PMU wants the same behaviour as if it had registered as > PERF_TYPE_RAW, so having "raw" in the name started to look like the > more intuitive option after all (plus being nice and short helps.) I appreciate the shortness, but I think it's misleading to tie this to "RAW" specifically, when really this is a capabiltiy to say "please let me try to init any events for non-dynamic types, in addition to whatever specific type I am registered with". > If anything, it's "events" that carries the implication that's proving hard > to capture precisely and concisely here, so maybe the answer to avoid > ambiguity is to lean further away from a "what it represents" to a "what it > actually does" naming - PERF_PMU_CAP_TYPE_RAW, anyone? I'm happy with TYPE in the name; it's just RAW specifically that I'm objecting to. > > Likewise, s/is_raw_pmu()/pmu_supports_common_cpu_events()/. > > Case in point: is it any more logical and expected that supporting common > CPU events implies a PMU should be offered software or breakpoint events as > well? Because that's what such a mere rename would currently mean :/ Yes, I think it is. > > > --- > > > > > > A further possibility is to automatically add the cap to PERF_TYPE_RAW > > > PMUs in perf_pmu_register() to have a single point-of-use condition; I'm > > > undecided... > > > > I reckon we don't need to automagically do that, but I reckon that > > is_raw_pmu()/pmu_supports_common_cpu_events() should only check the cap, > > and we don't read anything special into any of > > PERF_TYPE_{RAW,HARDWARE,HW_CACHE}. > > OK, but that would then necessitate having to explicitly add the cap to all > 15-odd other drivers which register as PERF_TYPE_RAW as well, at which point > it starts to look like a more general "I am a CPU PMU in terms of most > typical assumptions you might want to make about that" flag... > > To clarify (and perhaps something for a v2 commit message), we currently > have 3 categories of PMU driver: > > 1: (Older/simpler CPUs) Registers as PERF_TYPE_RAW, wants > PERF_TYPE_RAW/HARDWARE/HW_CACHE events > 2: (Heterogeneous CPUs) Registers as dynamic type, wants > PERF_TYPE_RAW/HARDWARE/HW_CACHE events plus events of its own type > 3: (Mostly uncore) Registers as dynamic type, only wants events of its own > type Sure, but I think that separating 1 and 2 is an artificial distinction, and what we really have is: (a) Wants to handle (some of) the non-dynamic/common/ABI types (in addition to whatever specific type it was registered with). Needs to have a switch statement somewhere in pmu::event_init(). (b) Only wants to handle the specific type the PMU was registered with. > My vested interest is in making category 3 the default behaviour, given that > the growing majority of new drivers are uncore (and I keep having to write > them...) Yes, we're aligned on that. > However unclear the type overlaps in category 1 might be, it's been > like that for 15 years, so I didn't feel compelled to churn fossils like > Alpha more than reasonably necessary. Category 2 is only these 5 drivers, so > a relatively small tweak to distinguish them from category 3 and let them > retain the effective category 1 behaviour (which remains the current one of > potentially still being offered software etc. events too) seemed like the > neatest way to make progress. I just think we should combine 1 and 2 (into categroy a as above), since that removes the need to treat RAW specially going forwards. > I'm not saying I'm necessarily against a general overhaul of CPU PMUs being > attempted too, just that it seems more like a whole other side-quest, and > I'd really like to slay the uncore-boilerplate dragon first. I think that adding the cap to those 15 PMUs would take less time than it has taken me to write this email, so I do not understand the objection. Mark.