From: Lukasz Luba <lukasz.luba@arm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
Vincent Guittot <vincent.guittot@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Zhang Rui <rui.zhang@intel.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Amit Daniel Kachhap <amit.kachhap@gmail.com>,
Javi Merino <javi.merino@kernel.org>,
Amit Kucheria <amit.kucheria@verdurent.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Quentin Perret <qperret@google.com>,
Rafael Wysocki <rjw@rjwysocki.net>,
"open list:THERMAL" <linux-pm@vger.kernel.org>
Subject: Re: [PATCH 2/2] thermal: cpufreq_cooling: Reuse effective_cpu_util()
Date: Thu, 30 Jul 2020 12:16:36 +0100 [thread overview]
Message-ID: <bc99342a-48ee-ce30-0116-4ba5c76787c2@arm.com> (raw)
In-Reply-To: <20200730062414.uq3ip7ukpu7nkiyg@vireshk-mac-ubuntu>
Hi Viresh,
On 7/30/20 7:24 AM, Viresh Kumar wrote:
> On 17-07-20, 11:46, Vincent Guittot wrote:
>> On Thu, 16 Jul 2020 at 16:24, Lukasz Luba <lukasz.luba@arm.com> wrote:
>>> On 7/16/20 12:56 PM, Peter Zijlstra wrote:
>>>> Currently cpufreq_cooling appears to estimate the CPU energy usage by
>>>> calculating the percentage of idle time using the per-cpu cpustat stuff,
>>>> which is pretty horrific.
>>>
>>> Even worse, it then *samples* the *current* CPU frequency at that
>>> particular point in time and assumes that when the CPU wasn't idle
>>> during that period - it had *this* frequency...
>>
>> So there is 2 problems in the power calculation of cpufreq cooling device :
>> - How to get an accurate utilization level of the cpu which is what
>> this patch is trying to fix because using idle time is just wrong
>> whereas scheduler utilization is frequency invariant
>
> Since this patch is targeted only towards fixing this particular
> problem, should I change something in the patch to make it acceptable
> ?
>
>> - How to get power estimate from this utilization level. And as you
>> pointed out, using the current freq which is not accurate.
>
> This should be tackled separately I believe.
>
I don't think that these two are separate. Furthermore, I think we
would need this kind of information also in future in the powercap.
I've discussed with Daniel this possible scenario.
We have a vendor who presented issue with the IPA input power and
pointed out these issues. Unfortunately, I don't have this vendor
phone but I assume it can last a few minutes without changing the
max allowed OPP. Based on their plots the frequency driven by the
governor is changing, also the idles are present during the IPA period.
Please give me a few days, because I am also plumbing these stuff
and would like to present it. These two interfaces: involving cpufreq
driver or fallback mode for utilization and EM.
Regards,
Lukasz
next prev parent reply other threads:[~2020-07-30 11:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 6:36 [PATCH 0/2] cpufreq_cooling: Get effective CPU utilization from scheduler Viresh Kumar
2020-07-14 6:36 ` [PATCH 1/2] sched/core: Rename and move schedutil_cpu_util to core.c Viresh Kumar
2020-07-14 12:52 ` Rafael J. Wysocki
2020-07-14 6:36 ` [PATCH 2/2] thermal: cpufreq_cooling: Reuse effective_cpu_util() Viresh Kumar
2020-07-14 8:23 ` Peter Zijlstra
2020-07-14 13:05 ` Rafael J. Wysocki
2020-07-15 7:32 ` Viresh Kumar
2020-07-15 12:47 ` Rafael J. Wysocki
2020-07-16 11:56 ` Peter Zijlstra
2020-07-16 14:24 ` Lukasz Luba
2020-07-16 15:43 ` Peter Zijlstra
2020-07-17 9:55 ` Lukasz Luba
2020-07-17 9:46 ` Vincent Guittot
2020-07-17 10:30 ` Lukasz Luba
2020-07-17 12:13 ` Vincent Guittot
2020-07-30 6:24 ` Viresh Kumar
2020-07-30 11:16 ` Lukasz Luba [this message]
2020-10-19 7:40 ` Viresh Kumar
2020-10-19 11:10 ` Lukasz Luba
2020-10-22 8:32 ` Viresh Kumar
2020-10-22 9:05 ` Peter Zijlstra
2020-10-22 11:06 ` Viresh Kumar
2020-10-22 11:30 ` Rafael J. Wysocki
2020-10-22 11:57 ` Peter Zijlstra
2020-10-22 12:07 ` Rafael J. Wysocki
2020-10-22 11:39 ` Peter Zijlstra
2020-07-17 10:14 ` Quentin Perret
2020-07-17 10:33 ` Quentin Perret
2020-07-17 10:43 ` Quentin Perret
2020-07-22 9:13 ` Viresh Kumar
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=bc99342a-48ee-ce30-0116-4ba5c76787c2@arm.com \
--to=lukasz.luba@arm.com \
--cc=amit.kachhap@gmail.com \
--cc=amit.kucheria@verdurent.com \
--cc=daniel.lezcano@linaro.org \
--cc=javi.merino@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qperret@google.com \
--cc=rjw@rjwysocki.net \
--cc=rui.zhang@intel.com \
--cc=vincent.guittot@linaro.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).