From patchwork Sat Jun 17 03:03:11 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Len Brown X-Patchwork-Id: 9793907 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 3A3CE60325 for ; Sat, 17 Jun 2017 03:04:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2CAF627F4B for ; Sat, 17 Jun 2017 03:04:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 20F0D283CB; Sat, 17 Jun 2017 03:04:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8EEEF27F4B for ; Sat, 17 Jun 2017 03:04:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752686AbdFQDE0 (ORCPT ); Fri, 16 Jun 2017 23:04:26 -0400 Received: from mail-qk0-f195.google.com ([209.85.220.195]:34676 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752391AbdFQDDY (ORCPT ); Fri, 16 Jun 2017 23:03:24 -0400 Received: by mail-qk0-f195.google.com with SMTP id d14so820673qkb.1; Fri, 16 Jun 2017 20:03:24 -0700 (PDT) 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=tRGKMa/mdIT45bb7Zm8g2zSJ/rmnNl8NrUlZjEoX67U=; b=RLDwUdMis/a8faeGo537bAZxz62Hv2v5jNwxt7AYz8MsWUYSGDHZS7TUnald4t80V2 Jr+B+kavBBrJ73Fom2d+PeveeH6Euryo7JeLhVnaRiRGBG/eqUBhKCzQ5cE5s1ZFAlQt MVBhGdBUWxVdrLdm6Fw7jKlf8YwwwVVqDGoCU3HawmqQgkAYv/oZH7RICssAdi9Tk0Id FTxydWnf5wCdWTe931RO56Bds7+ZIujoMw1pP/5LwozFEYVsBf+NoPARDYUQIU1vR9yM XrReUfD7uZUQWTlmhNm6u+3W6wETOTHOcxrNG2PIrrjFZEkoBGcRyL6hIPhgKmEuFhLg cq7g== 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=tRGKMa/mdIT45bb7Zm8g2zSJ/rmnNl8NrUlZjEoX67U=; b=GB5N/yQybdPUKEsDnhWOjE0/tYu6PsWBxhryDjpzrtzZckmRbcibmHrcPhYwWimeR2 p7rhFbg5JRgsWZkhHavqpBl3G+iN/ENyJ6F7nS0E5/qNc0RedxGR9wTojB0VA0AS+qnI 3GWm73FlSAsrkJ2Xp3XcO8IVidpKnzU3wIwK5EbUDvYsYqNFBx4If8yq9owWF9IALxq3 lVPAgocuhuatizKFstrNRR7oOQMg6GK8qrg9yoOenDXcBoJxE3cgLSRBnIl+eYs+7yBd pXwiGJTFMSQmEd0Jjjh1FXzByXjW65AvE6ojjGJGvBmHLiVr3WYTe4QAp2QXu5bT1R8a LH/A== X-Gm-Message-State: AKS2vOwVyvVB1GcuvXR6btYdlpEnLXYATfR60Cyi0RLWDpOz9j8ZEWqR uCAT/ZyqeJ4XLg== X-Received: by 10.55.56.149 with SMTP id f143mr15540318qka.73.1497668603331; Fri, 16 Jun 2017 20:03:23 -0700 (PDT) Received: from localhost.localdomain (pool-173-48-65-169.bstnma.fios.verizon.net. [173.48.65.169]) by smtp.gmail.com with ESMTPSA id g34sm2983335qta.46.2017.06.16.20.03.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Jun 2017 20:03:22 -0700 (PDT) From: Len Brown To: rafael@kernel.org Cc: x86@kernel.org, srinivas.pandruvada@linux.intel.com, peterz@infradead.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Len Brown Subject: [PATCH 1/4] x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" Date: Fri, 16 Jun 2017 20:03:11 -0700 Message-Id: X-Mailer: git-send-email 2.7.4 In-Reply-To: <1497668594-9266-1-git-send-email-lenb@kernel.org> References: <1497668594-9266-1-git-send-email-lenb@kernel.org> Reply-To: Len Brown Organization: Intel Open Source Technology Center Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Len Brown 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 Reviewed-by: Thomas Gleixner --- 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 #include #include -#include /* * 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)