From nobody Tue Jun 30 11:10:18 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91A95C433F5 for ; Tue, 18 Jan 2022 11:18:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239604AbiARLSF (ORCPT ); Tue, 18 Jan 2022 06:18:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40488 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239301AbiARLRz (ORCPT ); Tue, 18 Jan 2022 06:17:55 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C454EC061574; Tue, 18 Jan 2022 03:17:54 -0800 (PST) Date: Tue, 18 Jan 2022 11:17:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1642504673; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AeyQQDdvBnfZe4EW3FOjv17VBwX637qs/wVp9i6fIw8=; b=Mc/NnBXE98n2CLDz+/klWJMcudDM3BVcrUWZm/Du2oCUwrAhL4XD3Ti4NzBNA8vuhfVnID wB2A+qbJ3WenzHweOp/6oPnQckSfUbngaPnLCjn1j33grkR+FmNSUcsWT9vnwONM1UmtPd pcOMrq/9fEqQhXcuXlsTZ6IgJYorgIlkfgSz3DrbT1KL1ylUS6qnFEjK0xl+pRVFTM6PaG 38BYZc5CVOmO/DpEzaQgzO33hvl6k8jdazxioNYJUCOGkHEc3sjxg2mgx4cf3gNNBtMjaA 4vilXCEAPciaDAl0yjxidQqivP3/PGdiCSVIAvdHZie0wcHHkrKTNM6NB7A+8w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1642504673; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AeyQQDdvBnfZe4EW3FOjv17VBwX637qs/wVp9i6fIw8=; b=tl1kgOz7G9jvjEbcbW3LoQfddi6zQ7xh4NLVIPOgQweyEih8wCz3O9U261Bx8Ne3RTW8i5 lvU3rKt2i6Ds7CCA== From: "tip-bot2 for Stephane Eranian" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: perf/urgent] perf/x86/rapl: fix AMD event handling Cc: Stephane Eranian , "Peter Zijlstra (Intel)" , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20220105185659.643355-1-eranian@google.com> References: <20220105185659.643355-1-eranian@google.com> MIME-Version: 1.0 Message-ID: <164250467243.16921.12614662338884193710.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the perf/urgent branch of tip: Commit-ID: 0036fb00a756a2f6e360d44e2e3d2200a8afbc9b Gitweb: https://git.kernel.org/tip/0036fb00a756a2f6e360d44e2e3d2200a= 8afbc9b Author: Stephane Eranian AuthorDate: Wed, 05 Jan 2022 10:56:59 -08:00 Committer: Peter Zijlstra CommitterDate: Tue, 18 Jan 2022 12:09:48 +01:00 perf/x86/rapl: fix AMD event handling The RAPL events exposed under /sys/devices/power/events should only reflect what the underlying hardware actually support. This is how it works on Intel RAPL and Intel core/uncore PMUs in general. But on AMD, this was not the case. All possible RAPL events were advertised. This is what it showed on an AMD Fam17h: $ ls /sys/devices/power/events/ energy-cores energy-gpu energy-pkg energy-psys energy-ram energy-cores.scale energy-gpu.scale energy-pkg.scale energy-psys.scale energy-ram.scale energy-cores.unit energy-gpu.unit energy-pkg.unit energy-psys.unit energy-ram.unit Yet, on AMD Fam17h, only energy-pkg is supported. This patch fixes the problem. Given the way perf_msr_probe() works, the amd_rapl_msrs[] table has to have all entries filled out and in particular the group field, otherwise perf_msr_probe() defaults to making the event visible. With the patch applied, the kernel now only shows was is actually supported: $ ls /sys/devices/power/events/ energy-pkg energy-pkg.scale energy-pkg.unit The patch also uses the RAPL_MSR_MASK because only the 32-bits LSB of the RAPL counters are relevant when reading power consumption. Signed-off-by: Stephane Eranian Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20220105185659.643355-1-eranian@google.com --- arch/x86/events/rapl.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c index 85feafa..77e3a47 100644 --- a/arch/x86/events/rapl.c +++ b/arch/x86/events/rapl.c @@ -536,11 +536,14 @@ static struct perf_msr intel_rapl_spr_msrs[] =3D { * - perf_msr_probe(PERF_RAPL_MAX) * - want to use same event codes across both architectures */ -static struct perf_msr amd_rapl_msrs[PERF_RAPL_MAX] =3D { - [PERF_RAPL_PKG] =3D { MSR_AMD_PKG_ENERGY_STATUS, &rapl_events_pkg_group= , test_msr }, +static struct perf_msr amd_rapl_msrs[] =3D { + [PERF_RAPL_PP0] =3D { 0, &rapl_events_cores_group, 0, false, 0 }, + [PERF_RAPL_PKG] =3D { MSR_AMD_PKG_ENERGY_STATUS, &rapl_events_pkg_group= , test_msr, false, RAPL_MSR_MASK }, + [PERF_RAPL_RAM] =3D { 0, &rapl_events_ram_group, 0, false, 0 }, + [PERF_RAPL_PP1] =3D { 0, &rapl_events_gpu_group, 0, false, 0 }, + [PERF_RAPL_PSYS] =3D { 0, &rapl_events_psys_group, 0, false, 0 }, }; =20 - static int rapl_cpu_offline(unsigned int cpu) { struct rapl_pmu *pmu =3D cpu_to_rapl_pmu(cpu);