Message ID | 20231128-powerflags-v1-1-87e8fe020a3d@weissschuh.net |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:ce62:0:b0:403:3b70:6f57 with SMTP id o2csp4150152vqx; Tue, 28 Nov 2023 10:55:14 -0800 (PST) X-Google-Smtp-Source: AGHT+IE4SJJxU6+BjYCAlZv9Crkml7FcCaux2ggz3A3ps/aKvchABsTOwgXONuFfikrF9fepFeaj X-Received: by 2002:a05:6a20:8096:b0:18b:d248:bafb with SMTP id c22-20020a056a20809600b0018bd248bafbmr12923125pza.25.1701197713898; Tue, 28 Nov 2023 10:55:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701197713; cv=none; d=google.com; s=arc-20160816; b=fHDUy++F539z2Fl3Kbw2mq+LfBI/8giWgJ1+/uAAWlMw2m6wnx2g9PHwq2oJAoR3aX R6vh76rS9ydoi1AyEe9rDgbrqLynW48sx4NVzYmyc2OwO2SFfRhfl+f1fd+AQJPFuhiM ALGR6bgEm1aAICgfGIOdBV8b9xetijmKqOTtKIWYh5og6AegJcR5QHrb9mKOHPeRR0Vy 1/7dmTvGYLRvURd9TJkZzC2/A68ejuPUUR6e+rizN8wW2aoatE92Et/e+pv7qdQuHRcu KqUwuInHUUQRnCWJITVv2ZoCh8yD00M3CuIU3cmTrG9Saomlc4be0+H7RJF1C+F6x3mk ZLvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=20vBNy0xRsKTtonWBc+sDI2GLBahtkyvIcGWwzZ8qZ4=; fh=qka7fwo6uOOgTYP7lrQpOGunK8t0yZx827jTFqrq01E=; b=QJzE/3Ae5bTfR7e0Z4a4SgdN0GK0t3ALq1XTgr0uNkaB5DHSDmXNAMSJz33oEmcSIf ZDsHCncUdgEzxVroH875xk5RMPNxKKgcGi668PdXJwuXQUFXCKI+hl9FI+6K+0EVJ0M6 MWwGjvxvZdHvKvu0Z4ni+v5OnPSv5TmQqFJ1dD/QvVKEd7XUMt/WuxRIL3uge5hMZ2cj NGU8VU1ZnMmEQzYlck2qWMiqdwaAXd7GCVqiWmi4VG8D7ikNC80ayCD2MDuvrFWx+6Xl WtvWDp2ucMTbCngoIBurT7R++9PZY+Lvk4maXUW8gR8VQ5Fe/jUk1LtiJ27YM3JXwPCA AHVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@weissschuh.net header.s=mail header.b=UsY78Z+o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id cu8-20020a056a00448800b006cd904df7a2si4658383pfb.112.2023.11.28.10.55.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Nov 2023 10:55:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@weissschuh.net header.s=mail header.b=UsY78Z+o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 56BCF8051A34; Tue, 28 Nov 2023 10:55:11 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230171AbjK1Syx (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Tue, 28 Nov 2023 13:54:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229944AbjK1Syw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 28 Nov 2023 13:54:52 -0500 Received: from todd.t-8ch.de (todd.t-8ch.de [IPv6:2a01:4f8:c010:41de::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4EE99131 for <linux-kernel@vger.kernel.org>; Tue, 28 Nov 2023 10:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=weissschuh.net; s=mail; t=1701197696; bh=g5ZQtgKHvReyc2FbFJdjdcOuj1Mex1OD2XH15wvt0xQ=; h=From:Date:Subject:To:Cc:From; b=UsY78Z+onca9EojgI9jD7Jla9fc3zmxsMioryJWG96SHdyXoUKgb3hkAodn3SkG3/ sbW0zkfwTSfBHP3/sb2loAGcb/X9InCqO5nFOKCvKzQBTurDYOmlJOnZouQAhkBHgd BvJx8zx1QDBLYxKPzsFnG1omOWdJcAEDWR042NiI= From: =?utf-8?q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net> Date: Tue, 28 Nov 2023 19:54:54 +0100 Subject: [PATCH] x86/cpu: Update power flags MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <20231128-powerflags-v1-1-87e8fe020a3d@weissschuh.net> X-B4-Tracking: v=1; b=H4sIAH03ZmUC/6tWKk4tykwtVrJSqFYqSi3LLM7MzwNyDHUUlJIzE vPSU3UzU4B8JSMDI2NDQyML3YL88tSitJzE9GJdi+RUM7NES7M0szRjJaCGgqLUtMwKsGHRsbW 1AEcnwoNcAAAA To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com> Cc: linux-kernel@vger.kernel.org, =?utf-8?q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net> X-Mailer: b4 0.12.4 X-Developer-Signature: v=1; a=ed25519-sha256; t=1701197695; l=1122; i=linux@weissschuh.net; s=20221212; h=from:subject:message-id; bh=g5ZQtgKHvReyc2FbFJdjdcOuj1Mex1OD2XH15wvt0xQ=; b=52wa1GJz31VPEzbWBaqm9xum2pA9yacoidwksoWRik5Os7VvN69m/qrOREF+DTTHV0Z0xNA/7 9/RtLohigCLA7HVojfPZOB7vtYDSBuWGOLf9y+3NY5R/CjbMPeBSxNP X-Developer-Key: i=linux@weissschuh.net; a=ed25519; pk=KcycQgFPX2wGR5azS7RhpBqedglOZVgRPfdFSPB1LNw= X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Tue, 28 Nov 2023 10:55:11 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783835093700033126 X-GMAIL-MSGID: 1783835093700033126 |
Series |
x86/cpu: Update power flags
|
|
Commit Message
Thomas Weißschuh
Nov. 28, 2023, 6:54 p.m. UTC
As described on page 99 of
"Processing Programming Reference (PPR) for AMD Family 19h Model 61h, Revision B1 Processor".
(AMD Documentation Hub Document 56713)
Tested on an "AMD Ryzen 7 7840U w/ Radeon 780M Graphics".
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
arch/x86/kernel/cpu/powerflags.c | 3 +++
1 file changed, 3 insertions(+)
---
base-commit: df60cee26a2e3d937a319229e335cb3f9c1f16d2
change-id: 20231128-powerflags-8ce66a96f6f3
Best regards,
Comments
On Tue, Nov 28, 2023 at 07:54:54PM +0100, Thomas Weißschuh wrote: > As described on page 99 of > "Processing Programming Reference (PPR) for AMD Family 19h Model 61h, Revision B1 Processor". > (AMD Documentation Hub Document 56713) > > Tested on an "AMD Ryzen 7 7840U w/ Radeon 780M Graphics". > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > --- > arch/x86/kernel/cpu/powerflags.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/kernel/cpu/powerflags.c b/arch/x86/kernel/cpu/powerflags.c > index fd6ec2aa0303..0c98405aeae2 100644 > --- a/arch/x86/kernel/cpu/powerflags.c > +++ b/arch/x86/kernel/cpu/powerflags.c > @@ -21,4 +21,7 @@ const char *const x86_power_flags[32] = { > "eff_freq_ro", /* Readonly aperf/mperf */ > "proc_feedback", /* processor feedback interface */ > "acc_power", /* accumulated power mechanism */ > + "connected_standby", /* connected standby */ > + "rapl", /* running average power limit */ > + "fast_cppc", /* fast collaborative processor performance control */ No need. The beginning of Documentation/arch/x86/cpuinfo.rst tries to explain why.
On 2023-11-28 20:12:17+0100, Borislav Petkov wrote: > On Tue, Nov 28, 2023 at 07:54:54PM +0100, Thomas Weißschuh wrote: > > As described on page 99 of > > "Processing Programming Reference (PPR) for AMD Family 19h Model 61h, Revision B1 Processor". > > (AMD Documentation Hub Document 56713) > > > > Tested on an "AMD Ryzen 7 7840U w/ Radeon 780M Graphics". > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > --- > > arch/x86/kernel/cpu/powerflags.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/arch/x86/kernel/cpu/powerflags.c b/arch/x86/kernel/cpu/powerflags.c > > index fd6ec2aa0303..0c98405aeae2 100644 > > --- a/arch/x86/kernel/cpu/powerflags.c > > +++ b/arch/x86/kernel/cpu/powerflags.c > > @@ -21,4 +21,7 @@ const char *const x86_power_flags[32] = { > > "eff_freq_ro", /* Readonly aperf/mperf */ > > "proc_feedback", /* processor feedback interface */ > > "acc_power", /* accumulated power mechanism */ > > + "connected_standby", /* connected standby */ > > + "rapl", /* running average power limit */ > > + "fast_cppc", /* fast collaborative processor performance control */ > > No need. > > The beginning of Documentation/arch/x86/cpuinfo.rst tries to explain > why. Isn't this introduction more about the cpuinfo "flags" fields? These power management flags have their own field "power management". Without the patch it looks like this on my machine in cpuinfo: power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14] [15] So they are already reported, but only their numeric value. Anyways, if it's not correct to have them then let's drop the patch. Thomas
On Tue, Nov 28, 2023 at 08:25:40PM +0100, Thomas Weißschuh wrote: > > The beginning of Documentation/arch/x86/cpuinfo.rst tries to explain > > why. > > Isn't this introduction more about the cpuinfo "flags" fields? That's why I said "tries to explain". See below - I've been meaning to write this for a long time now. > power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14] [15] Yeah, nothing cares about those - see below. Thx. --- diff --git a/Documentation/arch/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst index 08246e8ac835..95c7ebcc13a9 100644 --- a/Documentation/arch/x86/cpuinfo.rst +++ b/Documentation/arch/x86/cpuinfo.rst @@ -13,6 +13,29 @@ or KVM want to expose the feature to a KVM guest, it can and should have an X86_FEATURE_* defined. These flags represent hardware features as well as software features. +The /proc/cpuinfo list is not exhaustive and represents an ill-fated +attempt from long time ago to put feature flags in an easy to find place +for userspace. However, + +* the amount of feature flags is growing by the CPU generation, leading +to unparseable and unwieldy /proc/cpuinfo + +* what is more, those feature flags even need to be in that file because +userspace doesn't even care about them - glibc et al already use CPUID +to find out what the target machine supports and what not. And even if +it doesn't do that and the hw supports CPUID faulting, userspace can +simply probe for the feature and figure out if it is supported or not + +* furthermore, those flag strings become an ABI the moment they appear +there and maintaining them forever when nothing even uses them is a lot +of wasted effort + +So, the current use of /proc/cpuinfo is to show features which the +kernel has *enabled* and supports. As in: the CPUID feature flag is +there, there's an additional setup which the kernel has done while +booting and the functionality is there and ready to use. A perfect +example for that is "user_shstk". + If users want to know if a feature is available on a given system, they try to find the flag in /proc/cpuinfo. If a given flag is present, it means that the kernel supports it and is currently making it available.
diff --git a/arch/x86/kernel/cpu/powerflags.c b/arch/x86/kernel/cpu/powerflags.c index fd6ec2aa0303..0c98405aeae2 100644 --- a/arch/x86/kernel/cpu/powerflags.c +++ b/arch/x86/kernel/cpu/powerflags.c @@ -21,4 +21,7 @@ const char *const x86_power_flags[32] = { "eff_freq_ro", /* Readonly aperf/mperf */ "proc_feedback", /* processor feedback interface */ "acc_power", /* accumulated power mechanism */ + "connected_standby", /* connected standby */ + "rapl", /* running average power limit */ + "fast_cppc", /* fast collaborative processor performance control */ };