From: Viresh Kumar <viresh.kumar@linaro.org>
To: Stratos Karafotis <stratosk@semaphore.gr>
Cc: "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred
Date: Wed, 9 Nov 2016 11:25:37 +0530 [thread overview]
Message-ID: <20161109055537.GA5544@vireshk-i7> (raw)
In-Reply-To: <5ea3831e-7743-d39f-1f02-96c915cc757e@semaphore.gr>
On 08-11-16, 21:25, Stratos Karafotis wrote:
> But this is the supposed behaviour of conservative governor. We want
> the CPU to increase the frequency in steps. The patch just resets
> the frequency to a lower frequency in case of idle.
>
> For argument's sake, let's assume that the governor timer is never
> deferred and runs every sampling period even on completely idle CPU.
There are no timers now :)
> And let's assume, for example, a burst load that runs every 100ms
> for 20ms. The default sampling rate is also 20ms.
> What would conservative do in case of that burst load? It would
> increase the frequency by one freq step after 20ms and then it would
> decrease the frequency 4 times by one frequency step. Most probably
> on the next burst load, the CPU will run on min frequency.
>
> I agree that maybe this is not ideal for performance but maybe this is
> how we want conservative governor to work (lazily increase and decrease
> frequency).
Idle periods are already accounted for while calculating system load by legacy
governors.
And the more and more I think about this, I am inclined towards your patch.
Maybe in a bit different form and commit log.
If we see how the governors were written initially, there were no deferred
timers. And so even if CPUs were idle, we will wake up to adjust the step.
Even if we want to make the behavior similar to that, then also we should
account of missed sampling periods both while decreasing or increasing
frequencies.
@Rafael: What do you think ?
--
viresh
next prev parent reply other threads:[~2016-11-09 5:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <076fb177-9cb3-4534-aadb-ebc2190d0751@email.android.com>
2016-11-08 8:32 ` [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred Viresh Kumar
2016-11-08 19:25 ` Stratos Karafotis
2016-11-09 5:55 ` Viresh Kumar [this message]
2016-11-09 18:27 ` Stratos Karafotis
2016-11-10 0:13 ` Rafael J. Wysocki
2016-11-10 15:48 ` Stratos Karafotis
2016-11-06 9:19 Stratos Karafotis
2016-11-07 6:12 ` Viresh Kumar
2016-11-07 17:27 ` Stratos Karafotis
2016-11-08 4:04 ` 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=20161109055537.GA5544@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=stratosk@semaphore.gr \
/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).