Received: by 2002:a05:7412:5112:b0:fa:6e18:a558 with SMTP id fm18csp1204355rdb; Wed, 24 Jan 2024 07:53:58 -0800 (PST) X-Google-Smtp-Source: AGHT+IGoj20LGoiWrEMfnoIF+LkEn7DNnoNQ6WqwUluICGjARM9R6bi+XA+pdJe/rlBmaSjVNrFV X-Received: by 2002:ac8:5f46:0:b0:42a:39ab:ab4d with SMTP id y6-20020ac85f46000000b0042a39abab4dmr2839256qta.100.1706111637998; Wed, 24 Jan 2024 07:53:57 -0800 (PST) Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id x7-20020a05622a000700b0042a5b40807bsi205934qtw.170.2024.01.24.07.53.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 07:53:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-37291-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-37291-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-37291-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id B0D2F1C24513 for ; Wed, 24 Jan 2024 15:53:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 210607CF03; Wed, 24 Jan 2024 15:53:49 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4A70F43154; Wed, 24 Jan 2024 15:53:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706111628; cv=none; b=BKg1nIsXVs7FpUNBs/D9IgD03c8OQtdEDWbZCxJj3G2ymX0LT7MR7lr6y5QWpao8Do95z7rRpUWuAySstctpoMgVWsPSCkHY2vFuJS4w+056WO156WtxqD3wyhKDz/J7JPbT68cUReX5mwDPaHNBxASu4jEcFUC5IwFmEGDj6cs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706111628; c=relaxed/simple; bh=dcCbF+oQLns+/Kp4ARJDoH2/E0G8EfELald1sVqSHzM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CbhQJ466r0TayTjTXlWPbmoDooZ5g/RCxNyNsm0Ipeh4QGuqhtKZimcpjge+D2OIf9XCDRmC/I7ABJBNlzKW3eFMJrI00Vv1zLNIrWqSQSHQWZIyKggg/7SY/l8Fvvj3b3jfbOBcMI2A60rjIe11GjTI0YWO105MD7fYZuU44PU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 8CCFE1FB; Wed, 24 Jan 2024 07:54:30 -0800 (PST) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.30.162]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C85593F762; Wed, 24 Jan 2024 07:53:43 -0800 (PST) Date: Wed, 24 Jan 2024 15:53:41 +0000 From: Mark Rutland To: James Clark Cc: Ian Rogers , acme@redhat.com, john.g.garry@oracle.com, leo.yan@linaro.org, linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, mike.leach@linaro.org, namhyung@kernel.org, suzuki.poulose@arm.com, tmricht@linux.ibm.com, will@kernel.org, linux-kernel@vger.kernel.org, Hector Martin , Marc Zyngier Subject: Re: [PATCH] perf print-events: make is_event_supported() more robust Message-ID: References: <20240116170348.463479-1-mark.rutland@arm.com> <5236cd64-c0ca-6d0e-137f-06a44f03ebc7@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5236cd64-c0ca-6d0e-137f-06a44f03ebc7@arm.com> On Mon, Jan 22, 2024 at 10:43:27AM +0000, James Clark wrote: > > > On 16/01/2024 17:03, Mark Rutland wrote: > > Currently the perf tool doesn't deteect support for extneded event types > > on Apple M1/M2 systems, and will not auto-expand plain PERF_EVENT_TYPE > > hardware events into per-PMU events. This is due to the detection of > > extended event types not handling mandatory filters required by the > > M1/M2 PMU driver. > > > > PMU drivers and the core perf_events code can require that > > perf_event_attr::exclude_* filters are configured in a specific way and > > may reject certain configurations of filters, for example: > > > > (a) Many PMUs lack support for any event filtering, and require all > > perf_event_attr::exclude_* bits to be clear. This includes Alpha's > > CPU PMU, and ARM CPU PMUs prior to the introduction of PMUv2 in > > ARMv7, > > > > (b) When /proc/sys/kernel/perf_event_paranoid >= 2, the perf core > > requires that perf_event_attr::exclude_kernel is set. > > > > (c) The Apple M1/M2 PMU requires that perf_event_attr::exclude_guest is > > set as the hardware PMU does not count while a guest is running (but > > might be extended in future to do so). > > > > In is_event_supported(), we try to account for cases (a) and (b), first > > attempting to open an event without any filters, and if this fails, > > retrying with perf_event_attr::exclude_kernel set. We do not account for > > case (c), or any other filters that drivers could theoretically require > > to be set. > > > > Thus is_event_supported() will fail to detect support for any events > > targetting an Apple M1/M2 PMU, even where events would be supported with > > perf_event_attr:::exclude_guest set. > > > > Since commit: > > > > 82fe2e45cdb00de4 ("perf pmus: Check if we can encode the PMU number in perf_event_attr.type") > > > > ... we use is_event_supported() to detect support for extended types, > > with the PMU ID encoded into the perf_event_attr::type. As above, on an > > Apple M1/M2 system this will always fail to detect that the event is > > supported, and consequently we fail to detect support for extended types > > even when these are supported, as they have been since commit: > > > > 5c816728651ae425 ("arm_pmu: Add PERF_PMU_CAP_EXTENDED_HW_TYPE capability") > > > > Due to this, the perf tool will not automatically expand plain > > PERF_TYPE_HARDWARE events into per-PMU events, even when all the > > necessary kernel support is present. > > > > This patch updates is_event_supported() to additionally try opening > > events with perf_event_attr::exclude_guest set, allowing support for > > events to be detected on Apple M1/M2 systems. I beleive that this is > > sufficient for all contemporary CPU PMU drivers, though in future it may > > be necessary to check for other combinations of filter bits. > > > > I've deliberately changed the check to not expect a specific error code > > for missing filters, as today ;the kernel may return a number of > > different error codes for missing filters (e.g. -EACCESS, -EINVAL, or > > -EOPNOTSUPP) depending on why and where the filter configuration is > > rejected, and retrying for any error is more robust. > > > > Note that this does not remove the need for commit: > > > > a24d9d9dc096fc0d ("perf parse-events: Make legacy events lower priority than sysfs/JSON") > > > > ... which is still necessary so that named-pmu/event/ events work on > > kernels without extended type support, even if the event name happens to > > be the same as a PERF_EVENT_TYPE_HARDWARE event (e.g. as is the case for > > the M1/M2 PMU's 'cycles' and 'instructions' events). > > > > Fixes: 82fe2e45cdb00de4 ("perf pmus: Check if we can encode the PMU number in perf_event_attr.type") > > Signed-off-by: Mark Rutland > > Cc: Arnaldo Carvalho de Melo > > Cc: Hector Martin > > Cc: Ian Rogers > > Cc: James Clark > > Cc: John Garry > > Cc: Leo Yan > > Cc: Marc Zyngier > > Cc: Mike Leach > > Cc: Namhyung Kim > > Cc: Suzuki K Poulose > > Cc: Thomas Richter > > Cc: Will Deacon > > --- > > tools/perf/util/print-events.c | 27 +++++++++++++++++++-------- > > 1 file changed, 19 insertions(+), 8 deletions(-) > > > > Tested-by: James Clark > > Tested on Juno and N1SDP, although I wouldn't have expected it to make a > difference on those platforms because they support exclude_guest=0. It's good to be certain, anyhow! I've folded that tag in for v2. > Although I do see an interaction with the test "Session topology" if I > hack the driver to behave like M1. The test has been failing (on > big.LITTLE) since commit 251aa040244a ("perf parse-events: Wildcard most > "numeric" events") but the result is that the test actually starts > passing with this change. I don't think that should really block this > though, it's likely going to require a separate fix which I will look into. IIUC that fix is: https://lore.kernel.org/lkml/20240124094358.489372-1-james.clark@arm.com/ .. right? Mark.