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 BBEEBC4725D for ; Mon, 22 Jan 2024 10:44:03 +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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zAszoygZe2xK2bikqvJweHu6SePZw7Ay0sRHdiEm+W8=; b=tvXDmdVMqrqj6t G07bz/ZEEOmb1dbLozOK3bqt4UbfvcglOrPK0dF7kGq8ph45O0eyJZshTILNa3EhKanM+1lBe/5Lw xmvv3gYTotFnYXPum5NpnA0ApV1O1KKXaDN3Vn2U1DpfBn2I1YIkbKlNsS64j4EPXydASiHqSJewh J36E+OEmfNPomSL46THrTp8siENw8MHAIf69Tl/KMwQEIxG3dGKbYn7FDipwFu/fHHVGA3Dl0Hw4H Z1Rc1xf4ABd3A6ZxgPBrDACI0D7DROUoJFcknePIHvKGAOO+o/OqzBqWbXNMa7jRJvGoDTV/Qtori kalphCj8d8dG5qkWxLxw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rRrmC-00BZbk-36; Mon, 22 Jan 2024 10:43:36 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rRrm9-00BZay-11 for linux-arm-kernel@lists.infradead.org; Mon, 22 Jan 2024 10:43:35 +0000 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 5D8C71FB; Mon, 22 Jan 2024 02:44:14 -0800 (PST) Received: from [192.168.1.100] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8B11C3F5A1; Mon, 22 Jan 2024 02:43:26 -0800 (PST) Message-ID: <5236cd64-c0ca-6d0e-137f-06a44f03ebc7@arm.com> Date: Mon, 22 Jan 2024 10:43:27 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] perf print-events: make is_event_supported() more robust Content-Language: en-US To: Mark Rutland , Ian Rogers Cc: 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 References: <20240116170348.463479-1-mark.rutland@arm.com> From: James Clark In-Reply-To: <20240116170348.463479-1-mark.rutland@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240122_024333_468427_7EB2BB67 X-CRM114-Status: GOOD ( 37.35 ) 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 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. 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. James _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel