* [PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable
@ 2017-02-21 4:45 Viresh Kumar
2017-02-23 23:36 ` Rafael J. Wysocki
0 siblings, 1 reply; 3+ messages in thread
From: Viresh Kumar @ 2017-02-21 4:45 UTC (permalink / raw)
To: Rafael Wysocki, Ingo Molnar, Peter Zijlstra
Cc: linaro-kernel, linux-pm, linux-kernel, Vincent Guittot, eas-dev,
Viresh Kumar
The rate_limit_us tunable is intended to reduce the possible overhead
from running the schedutil governor. However, that overhead can be
divided into two separate parts: the governor computations and the
invocation of the scaling driver to set the CPU frequency. The latter
is where the real overhead comes from. The former is much less
expensive in terms of execution time and running it every time the
governor callback is invoked by the scheduler, after rate_limit_us
interval has passed since the last frequency update, would not be a
problem.
For this reason, redefine the rate_limit_us tunable so that it means the
minimum time that has to pass between two consecutive invocations of the
scaling driver by the schedutil governor (to set the CPU frequency).
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V1->V2: Update $subject and commit log (Rafael)
kernel/sched/cpufreq_schedutil.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index fd4659313640..306d97e7b57c 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -92,14 +92,13 @@ static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
{
struct cpufreq_policy *policy = sg_policy->policy;
- sg_policy->last_freq_update_time = time;
-
if (policy->fast_switch_enabled) {
if (sg_policy->next_freq == next_freq) {
trace_cpu_frequency(policy->cur, smp_processor_id());
return;
}
sg_policy->next_freq = next_freq;
+ sg_policy->last_freq_update_time = time;
next_freq = cpufreq_driver_fast_switch(policy, next_freq);
if (next_freq == CPUFREQ_ENTRY_INVALID)
return;
@@ -108,6 +107,7 @@ static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
trace_cpu_frequency(next_freq, smp_processor_id());
} else if (sg_policy->next_freq != next_freq) {
sg_policy->next_freq = next_freq;
+ sg_policy->last_freq_update_time = time;
sg_policy->work_in_progress = true;
irq_work_queue(&sg_policy->irq_work);
}
--
2.7.1.410.g6faf27b
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable
2017-02-21 4:45 [PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable Viresh Kumar
@ 2017-02-23 23:36 ` Rafael J. Wysocki
2017-02-24 2:29 ` Viresh Kumar
0 siblings, 1 reply; 3+ messages in thread
From: Rafael J. Wysocki @ 2017-02-23 23:36 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, Ingo Molnar, Peter Zijlstra, Lists linaro-kernel,
Linux PM, Linux Kernel Mailing List, Vincent Guittot, eas-dev
On Tue, Feb 21, 2017 at 5:45 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> The rate_limit_us tunable is intended to reduce the possible overhead
> from running the schedutil governor. However, that overhead can be
> divided into two separate parts: the governor computations and the
> invocation of the scaling driver to set the CPU frequency. The latter
> is where the real overhead comes from. The former is much less
> expensive in terms of execution time and running it every time the
> governor callback is invoked by the scheduler, after rate_limit_us
> interval has passed since the last frequency update, would not be a
> problem.
>
> For this reason, redefine the rate_limit_us tunable so that it means the
> minimum time that has to pass between two consecutive invocations of the
> scaling driver by the schedutil governor (to set the CPU frequency).
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
I'd prefer this to spend some time in linux-next before it goes into
the mainline, so I will queue it up for 4.12 if no one objects by the
end of the next week.
Thanks,
Rafael
> ---
> V1->V2: Update $subject and commit log (Rafael)
>
> kernel/sched/cpufreq_schedutil.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index fd4659313640..306d97e7b57c 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -92,14 +92,13 @@ static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
> {
> struct cpufreq_policy *policy = sg_policy->policy;
>
> - sg_policy->last_freq_update_time = time;
> -
> if (policy->fast_switch_enabled) {
> if (sg_policy->next_freq == next_freq) {
> trace_cpu_frequency(policy->cur, smp_processor_id());
> return;
> }
> sg_policy->next_freq = next_freq;
> + sg_policy->last_freq_update_time = time;
> next_freq = cpufreq_driver_fast_switch(policy, next_freq);
> if (next_freq == CPUFREQ_ENTRY_INVALID)
> return;
> @@ -108,6 +107,7 @@ static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
> trace_cpu_frequency(next_freq, smp_processor_id());
> } else if (sg_policy->next_freq != next_freq) {
> sg_policy->next_freq = next_freq;
> + sg_policy->last_freq_update_time = time;
> sg_policy->work_in_progress = true;
> irq_work_queue(&sg_policy->irq_work);
> }
> --
> 2.7.1.410.g6faf27b
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable
2017-02-23 23:36 ` Rafael J. Wysocki
@ 2017-02-24 2:29 ` Viresh Kumar
0 siblings, 0 replies; 3+ messages in thread
From: Viresh Kumar @ 2017-02-24 2:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael Wysocki, Ingo Molnar, Peter Zijlstra, Lists linaro-kernel,
Linux PM, Linux Kernel Mailing List, Vincent Guittot, eas-dev
On 24-02-17, 00:36, Rafael J. Wysocki wrote:
> I'd prefer this to spend some time in linux-next before it goes into
> the mainline, so I will queue it up for 4.12 if no one objects by the
> end of the next week.
Sure. Thanks.
--
viresh
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-02-24 2:29 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-21 4:45 [PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable Viresh Kumar
2017-02-23 23:36 ` Rafael J. Wysocki
2017-02-24 2:29 ` Viresh Kumar
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).