From: Al Stone <ahs3@redhat.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
Ashwin Chaugule <ashwin.chaugule@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>,
linux acpi <linux-acpi@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"rwells@codeaurora.org" <rwells@codeaurora.org>
Subject: Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting
Date: Wed, 11 May 2016 17:08:10 -0600 [thread overview]
Message-ID: <359d426f-4e6d-6411-2bb0-0daa215dbbb4@redhat.com> (raw)
In-Reply-To: <20160422053020.GB2235@vireshk-i7>
On 04/21/2016 11:30 PM, Viresh Kumar wrote:
> On 19-04-16, 16:12, Ashwin Chaugule wrote:
>> + Ryan
>>
>> Hi Al,
>>
>> On 18 April 2016 at 20:11, Al Stone <ahs3@redhat.com> wrote:
>>> When CPPC is being used by ACPI on arm64, user space tools such as
>>> cpupower report CPU frequency values from sysfs that are incorrect.
>>>
>>> What the driver was doing was reporting the values given by ACPI tables
>>> in whatever scale was used to provide them. However, the ACPI spec
>>> defines the CPPC values as unitless abstract numbers. Internal kernel
>>> structures such as struct perf_cap, in contrast, expect these values
>>> to be in KHz. When these struct values get reported via sysfs, the
>>> user space tools also assume they are in KHz, causing them to report
>>> incorrect values (for example, reporting a CPU frequency of 1MHz when
>>> it should be 1.8GHz).
>>>
>>> While the investigation for a long term fix proceeds (several options
>>> are being explored, some of which may require spec changes or other
>>> much more invasive fixes), this patch forces the values read by CPPC
>>> to be read in KHz, regardless of what they actually represent.
>>>
>>> The downside is that this approach has some assumptions:
>>>
>>> (1) It relies on SMBIOS3 being used, *and* that the Max Frequency
>>> value for a processor is set to a non-zero value.
>>>
>>> (2) It assumes that all processors run at the same speed. This
>>> patch retrieves the first CPU Max Frequency from a type 4 DMI
>>> record that it can find. This may not be an issue, however, as a
>>> sampling of DMI data on x86 and arm64 indicates there is often only
>>> one such record regardless.
>
> Don't we have any big LITTLE ARM servers yet ? Or we will not have them at all ?
My apologies, but I missed this question earlier and just now noticed
it. AFAIK, there are no big.LITTLE ARM servers yet. That doesn't mean
there aren't any, or that no one is planning one; I just don't know of
any. I have been in discussions about doing that, but in the past those
have ended up concluding that there is probably no need for that level
of power management in a server.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@redhat.com
-----------------------------------
next prev parent reply other threads:[~2016-05-11 23:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-19 0:11 [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting Al Stone
2016-04-19 20:12 ` Ashwin Chaugule
2016-04-19 22:53 ` Al Stone
2016-04-26 18:46 ` rwells
2016-04-22 5:30 ` Viresh Kumar
2016-04-22 12:47 ` Rafael J. Wysocki
2016-05-11 23:08 ` Al Stone [this message]
2016-04-22 12:52 ` Rafael J. Wysocki
2016-04-21 14:53 ` Alexey Klimov
2016-04-21 16:49 ` Al Stone
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=359d426f-4e6d-6411-2bb0-0daa215dbbb4@redhat.com \
--to=ahs3@redhat.com \
--cc=ashwin.chaugule@linaro.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=rwells@codeaurora.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).