Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1674001

[PATCH 1/4] x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"

Path csiph.com!news.redatomik.org!aioe.org!bofh.it!news.nic.it!robomod
From Len Brown <lenb@kernel.org>
Newsgroups linux.kernel
Subject [PATCH 1/4] x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"
Date Sat, 24 Jun 2017 07:20:01 +0200
Message-ID <tVLEd-3Fl-5@gated-at.bofh.it> (permalink)
References <tVLEd-3Fl-3@gated-at.bofh.it>
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :reply-to:organization; bh=/PzvSFWscC1mrD45OIzhR+aE4RpvJGsLApPrClm9KZg=; b=P5+2tweBR0RZDgxf+h8BWVevimz6rcMy+HsM3NcYmfEmidu2R74FYNrpqFIHfdU23z s0EQ+n4PcApYol8cFoXGlUnyoPV0ReqDZU3NsJR2p64Niz6nE0Y0aXtBtqyxb2hfnaBX xwwH8tRAzmPbhd+oU8yRxZ2IB2tHI0Rg46Yh4ECXcdu4JGN0GEtFUiKCd23Eunc5BGut 3MYcHowJcqM46QppXD++6GCUc1VdanLaeo2EISQGHoTWC5GqVe662AWplfXyU05Wi7xJ Gv1ERStW81r53iJyDMiNGjI+DdjAYIzs80NhRsXL3gDmYEt705wUJMX6qqgRCbpMgK9I hdDA==
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references:reply-to:organization; bh=/PzvSFWscC1mrD45OIzhR+aE4RpvJGsLApPrClm9KZg=; b=su7IWDiA8ho2GJeNlVmPaYVTtFZU8mE+IxzpO8z2If+icrveRA2P8nFuiKGnL55r4s YFfyD/JSEWBz6mKLG6GI2OjlBTrLA8SxuZYnDoO0W3Vvy8MpEs63ta+LGEIHcVfmvsqJ 5/GfBWa9E66aRt86nPRNHxi/YPsFSOB9RH4m/wqn6zCMSXs7Hv3dQBW1QGUyKdGDV+a+ ysJrpFqDioudToRpvEA+9VVk5RImaTixqkGZlTayLmPMBy6h4BxYYMbYq1ei0XpWhpyc DnmJe+6kEYlcws2LpFK8FKY5Imf5g3RBF79iTq0xwunVKBOEqRibSfvdWU8LetFqxzH8 EEkA==
X-Gm-Message-State AKS2vOx088IGY6obcFEe1Wk5qMBWkVf0BJH9yX4BKXsS0sV5MRCF6Zxr mhQaCCDQhvvCxg==
X-Received by 10.237.53.79 with SMTP id b15mr4416507qte.83.1498281121252; Fri, 23 Jun 2017 22:12:01 -0700 (PDT)
X-Mailer git-send-email 2.7.4
Reply-To Len Brown <lenb@kernel.org>
Organization Intel Open Source Technology Center
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 84
X-Original-Cc x86@kernel.org, srinivas.pandruvada@linux.intel.com, peterz@infradead.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Len Brown <len.brown@intel.com>
X-Original-Date Fri, 23 Jun 2017 22:11:51 -0700
X-Original-Message-ID <e3f0ab4d677eb1337999731f1a98022caa8a796a.1498280509.git.len.brown@intel.com>
X-Original-References <1498281114-3868-1-git-send-email-lenb@kernel.org>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1674001

Show key headers only | View raw


From: Len Brown <len.brown@intel.com>

cpufreq_quick_get() allows cpufreq drivers to over-ride cpu_khz
that is otherwise reported in x86 /proc/cpuinfo "cpu MHz".

There are four problems with this scheme,
any of them is sufficient justification to delete it.

1. Depending on which cpufreq driver is loaded, the behavior
   of this field is different.

2. Distros complain that they have to explain to users
   why and how this field changes.  Distros have requested a constant.

3. The two major providers of this information, acpi_cpufreq
   and intel_pstate, both "get it wrong" in different ways.

   acpi_cpufreq lies to the user by telling them that
   they are running at whatever frequency was last
   requested by software.

   intel_pstate lies to the user by telling them that
   they are running at the average frequency computed
   over an undefined measurement.  But an average computed
   over an undefined interval, is itself, undefined...

4. On modern processors, user space utilities, such as
   turbostat(1), are more accurate and more precise, while
   supporing concurrent measurement over arbitrary intervals.

Users who have been consulting /proc/cpuinfo to
track changing CPU frequency will be dissapointed that
it no longer wiggles -- perhaps being unaware of the
limitations of the information they have been consuming.

Yes, they can change their scripts to look in sysfs
cpufreq/scaling_cur_frequency.  Here they will find the same
data of dubious quality here removed from /proc/cpuinfo.
The value in sysfs will be addressed in a subsequent patch
to address issues 1-3, above.

Issue 4 will remain -- users that really care about
accurate frequency information should not be using either
proc or sysfs kernel interfaces.
They should be using using turbostat(8), or a similar
purpose-built analysis tool.

Signed-off-by: Len Brown <len.brown@intel.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/kernel/cpu/proc.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 6df621a..218f798 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -2,7 +2,6 @@
 #include <linux/timex.h>
 #include <linux/string.h>
 #include <linux/seq_file.h>
-#include <linux/cpufreq.h>
 
 /*
  *	Get CPU information for use by the procfs.
@@ -76,14 +75,9 @@ static int show_cpuinfo(struct seq_file *m, void *v)
 	if (c->microcode)
 		seq_printf(m, "microcode\t: 0x%x\n", c->microcode);
 
-	if (cpu_has(c, X86_FEATURE_TSC)) {
-		unsigned int freq = cpufreq_quick_get(cpu);
-
-		if (!freq)
-			freq = cpu_khz;
+	if (cpu_has(c, X86_FEATURE_TSC))
 		seq_printf(m, "cpu MHz\t\t: %u.%03u\n",
-			   freq / 1000, (freq % 1000));
-	}
+			   cpu_khz / 1000, (cpu_khz % 1000));
 
 	/* Cache size */
 	if (c->x86_cache_size >= 0)
-- 
2.7.4

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

[PATCH 1/4] x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" Len Brown <lenb@kernel.org> - 2017-06-24 07:20 +0200

csiph-web