2012-10-23 07:28:05 +08:00
|
|
|
/*
|
|
|
|
* drivers/cpufreq/cpufreq_governor.c
|
|
|
|
*
|
|
|
|
* CPUFREQ governors common code
|
|
|
|
*
|
2012-10-26 06:47:42 +08:00
|
|
|
* Copyright (C) 2001 Russell King
|
|
|
|
* (C) 2003 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>.
|
|
|
|
* (C) 2003 Jun Nakajima <jun.nakajima@intel.com>
|
|
|
|
* (C) 2009 Alexander Clouter <alex@digriz.org.uk>
|
|
|
|
* (c) 2012 Viresh Kumar <viresh.kumar@linaro.org>
|
|
|
|
*
|
2012-10-23 07:28:05 +08:00
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
2012-10-26 06:47:42 +08:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2012-10-23 07:28:05 +08:00
|
|
|
#include <linux/export.h>
|
|
|
|
#include <linux/kernel_stat.h>
|
2013-03-27 23:58:58 +08:00
|
|
|
#include <linux/slab.h>
|
2012-10-26 06:47:42 +08:00
|
|
|
|
|
|
|
#include "cpufreq_governor.h"
|
|
|
|
|
2016-02-07 23:01:31 +08:00
|
|
|
DEFINE_MUTEX(dbs_data_mutex);
|
|
|
|
EXPORT_SYMBOL_GPL(dbs_data_mutex);
|
|
|
|
|
2016-02-11 20:01:15 +08:00
|
|
|
/* Common sysfs tunables */
|
|
|
|
/**
|
|
|
|
* store_sampling_rate - update sampling rate effective immediately if needed.
|
|
|
|
*
|
|
|
|
* If new rate is smaller than the old, simply updating
|
|
|
|
* dbs.sampling_rate might not be appropriate. For example, if the
|
|
|
|
* original sampling_rate was 1 second and the requested new sampling rate is 10
|
|
|
|
* ms because the user needs immediate reaction from ondemand governor, but not
|
|
|
|
* sure if higher frequency will be required or not, then, the governor may
|
|
|
|
* change the sampling rate too late; up to 1 second later. Thus, if we are
|
|
|
|
* reducing the sampling rate, we need to make the new value effective
|
|
|
|
* immediately.
|
|
|
|
*
|
|
|
|
* On the other hand, if new rate is larger than the old, then we may evaluate
|
|
|
|
* the load too soon, and it might we worth updating sample_delay_ns then as
|
|
|
|
* well.
|
|
|
|
*
|
|
|
|
* This must be called with dbs_data->mutex held, otherwise traversing
|
|
|
|
* policy_dbs_list isn't safe.
|
|
|
|
*/
|
|
|
|
ssize_t store_sampling_rate(struct dbs_data *dbs_data, const char *buf,
|
|
|
|
size_t count)
|
|
|
|
{
|
|
|
|
struct policy_dbs_info *policy_dbs;
|
|
|
|
unsigned int rate;
|
|
|
|
int ret;
|
|
|
|
ret = sscanf(buf, "%u", &rate);
|
|
|
|
if (ret != 1)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
dbs_data->sampling_rate = max(rate, dbs_data->min_sampling_rate);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We are operating under dbs_data->mutex and so the list and its
|
|
|
|
* entries can't be freed concurrently.
|
|
|
|
*/
|
|
|
|
list_for_each_entry(policy_dbs, &dbs_data->policy_dbs_list, list) {
|
|
|
|
mutex_lock(&policy_dbs->timer_mutex);
|
|
|
|
/*
|
|
|
|
* On 32-bit architectures this may race with the
|
|
|
|
* sample_delay_ns read in dbs_update_util_handler(), but that
|
|
|
|
* really doesn't matter. If the read returns a value that's
|
|
|
|
* too big, the sample will be skipped, but the next invocation
|
|
|
|
* of dbs_update_util_handler() (when the update has been
|
|
|
|
* completed) will take a sample. If the returned value is too
|
|
|
|
* small, the sample will be taken immediately, but that isn't a
|
|
|
|
* problem, as we want the new rate to take effect immediately
|
|
|
|
* anyway.
|
|
|
|
*
|
|
|
|
* If this runs in parallel with dbs_work_handler(), we may end
|
|
|
|
* up overwriting the sample_delay_ns value that it has just
|
|
|
|
* written, but the difference should not be too big and it will
|
|
|
|
* be corrected next time a sample is taken, so it shouldn't be
|
|
|
|
* significant.
|
|
|
|
*/
|
|
|
|
gov_update_sample_delay(policy_dbs, dbs_data->sampling_rate);
|
|
|
|
mutex_unlock(&policy_dbs->timer_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(store_sampling_rate);
|
|
|
|
|
cpufreq: governor: New sysfs show/store callbacks for governor tunables
The ondemand and conservative governors use the global-attr or freq-attr
structures to represent sysfs attributes corresponding to their tunables
(which of them is actually used depends on whether or not different
policy objects can use the same governor with different tunables at the
same time and, consequently, on where those attributes are located in
sysfs).
Unfortunately, in the freq-attr case, the standard cpufreq show/store
sysfs attribute callbacks are applied to the governor tunable attributes
and they always acquire the policy->rwsem lock before carrying out the
operation. That may lead to an ABBA deadlock if governor tunable
attributes are removed under policy->rwsem while one of them is being
accessed concurrently (if sysfs attributes removal wins the race, it
will wait for the access to complete with policy->rwsem held while the
attribute callback will block on policy->rwsem indefinitely).
We attempted to address this issue by dropping policy->rwsem around
governor tunable attributes removal (that is, around invocations of the
->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT)
in cpufreq_set_policy(), but that opened up race conditions that had not
been possible with policy->rwsem held all the time. Therefore
policy->rwsem cannot be dropped in cpufreq_set_policy() at any point,
but the deadlock situation described above must be avoided too.
To that end, use the observation that in principle governor tunables may
be represented by the same data type regardless of whether the governor
is system-wide or per-policy and introduce a new structure, struct
governor_attr, for representing them and new corresponding macros for
creating show/store sysfs callbacks for them. Also make their parent
kobject use a new kobject type whose default show/store callbacks are
not related to the standard core cpufreq ones in any way (and they don't
acquire policy->rwsem in particular).
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Juri Lelli <juri.lelli@arm.com>
Tested-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
[ rjw: Subject & changelog + rebase ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-09 11:31:33 +08:00
|
|
|
static inline struct dbs_data *to_dbs_data(struct kobject *kobj)
|
2013-03-27 23:58:58 +08:00
|
|
|
{
|
cpufreq: governor: New sysfs show/store callbacks for governor tunables
The ondemand and conservative governors use the global-attr or freq-attr
structures to represent sysfs attributes corresponding to their tunables
(which of them is actually used depends on whether or not different
policy objects can use the same governor with different tunables at the
same time and, consequently, on where those attributes are located in
sysfs).
Unfortunately, in the freq-attr case, the standard cpufreq show/store
sysfs attribute callbacks are applied to the governor tunable attributes
and they always acquire the policy->rwsem lock before carrying out the
operation. That may lead to an ABBA deadlock if governor tunable
attributes are removed under policy->rwsem while one of them is being
accessed concurrently (if sysfs attributes removal wins the race, it
will wait for the access to complete with policy->rwsem held while the
attribute callback will block on policy->rwsem indefinitely).
We attempted to address this issue by dropping policy->rwsem around
governor tunable attributes removal (that is, around invocations of the
->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT)
in cpufreq_set_policy(), but that opened up race conditions that had not
been possible with policy->rwsem held all the time. Therefore
policy->rwsem cannot be dropped in cpufreq_set_policy() at any point,
but the deadlock situation described above must be avoided too.
To that end, use the observation that in principle governor tunables may
be represented by the same data type regardless of whether the governor
is system-wide or per-policy and introduce a new structure, struct
governor_attr, for representing them and new corresponding macros for
creating show/store sysfs callbacks for them. Also make their parent
kobject use a new kobject type whose default show/store callbacks are
not related to the standard core cpufreq ones in any way (and they don't
acquire policy->rwsem in particular).
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Juri Lelli <juri.lelli@arm.com>
Tested-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
[ rjw: Subject & changelog + rebase ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-09 11:31:33 +08:00
|
|
|
return container_of(kobj, struct dbs_data, kobj);
|
2013-03-27 23:58:58 +08:00
|
|
|
}
|
|
|
|
|
cpufreq: governor: New sysfs show/store callbacks for governor tunables
The ondemand and conservative governors use the global-attr or freq-attr
structures to represent sysfs attributes corresponding to their tunables
(which of them is actually used depends on whether or not different
policy objects can use the same governor with different tunables at the
same time and, consequently, on where those attributes are located in
sysfs).
Unfortunately, in the freq-attr case, the standard cpufreq show/store
sysfs attribute callbacks are applied to the governor tunable attributes
and they always acquire the policy->rwsem lock before carrying out the
operation. That may lead to an ABBA deadlock if governor tunable
attributes are removed under policy->rwsem while one of them is being
accessed concurrently (if sysfs attributes removal wins the race, it
will wait for the access to complete with policy->rwsem held while the
attribute callback will block on policy->rwsem indefinitely).
We attempted to address this issue by dropping policy->rwsem around
governor tunable attributes removal (that is, around invocations of the
->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT)
in cpufreq_set_policy(), but that opened up race conditions that had not
been possible with policy->rwsem held all the time. Therefore
policy->rwsem cannot be dropped in cpufreq_set_policy() at any point,
but the deadlock situation described above must be avoided too.
To that end, use the observation that in principle governor tunables may
be represented by the same data type regardless of whether the governor
is system-wide or per-policy and introduce a new structure, struct
governor_attr, for representing them and new corresponding macros for
creating show/store sysfs callbacks for them. Also make their parent
kobject use a new kobject type whose default show/store callbacks are
not related to the standard core cpufreq ones in any way (and they don't
acquire policy->rwsem in particular).
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Juri Lelli <juri.lelli@arm.com>
Tested-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
[ rjw: Subject & changelog + rebase ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-09 11:31:33 +08:00
|
|
|
static inline struct governor_attr *to_gov_attr(struct attribute *attr)
|
|
|
|
{
|
|
|
|
return container_of(attr, struct governor_attr, attr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t governor_show(struct kobject *kobj, struct attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
struct dbs_data *dbs_data = to_dbs_data(kobj);
|
|
|
|
struct governor_attr *gattr = to_gov_attr(attr);
|
|
|
|
int ret = -EIO;
|
|
|
|
|
|
|
|
if (gattr->show)
|
|
|
|
ret = gattr->show(dbs_data, buf);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t governor_store(struct kobject *kobj, struct attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
struct dbs_data *dbs_data = to_dbs_data(kobj);
|
|
|
|
struct governor_attr *gattr = to_gov_attr(attr);
|
|
|
|
int ret = -EIO;
|
|
|
|
|
|
|
|
mutex_lock(&dbs_data->mutex);
|
|
|
|
|
|
|
|
if (gattr->store)
|
|
|
|
ret = gattr->store(dbs_data, buf, count);
|
|
|
|
|
|
|
|
mutex_unlock(&dbs_data->mutex);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sysfs Ops for accessing governor attributes.
|
|
|
|
*
|
|
|
|
* All show/store invocations for governor specific sysfs attributes, will first
|
|
|
|
* call the below show/store callbacks and the attribute specific callback will
|
|
|
|
* be called from within it.
|
|
|
|
*/
|
|
|
|
static const struct sysfs_ops governor_sysfs_ops = {
|
|
|
|
.show = governor_show,
|
|
|
|
.store = governor_store,
|
|
|
|
};
|
|
|
|
|
2016-02-06 20:50:24 +08:00
|
|
|
void dbs_check_cpu(struct cpufreq_policy *policy)
|
2012-10-26 06:47:42 +08:00
|
|
|
{
|
2016-02-06 20:50:24 +08:00
|
|
|
int cpu = policy->cpu;
|
2016-02-07 23:09:51 +08:00
|
|
|
struct dbs_governor *gov = dbs_governor_of(policy);
|
2016-02-07 23:24:26 +08:00
|
|
|
struct policy_dbs_info *policy_dbs = policy->governor_data;
|
|
|
|
struct dbs_data *dbs_data = policy_dbs->dbs_data;
|
2012-10-26 06:47:42 +08:00
|
|
|
struct od_dbs_tuners *od_tuners = dbs_data->tuners;
|
2016-02-09 11:31:32 +08:00
|
|
|
unsigned int sampling_rate = dbs_data->sampling_rate;
|
|
|
|
unsigned int ignore_nice = dbs_data->ignore_nice_load;
|
2012-10-26 06:47:42 +08:00
|
|
|
unsigned int max_load = 0;
|
|
|
|
unsigned int j;
|
|
|
|
|
2016-02-07 23:09:51 +08:00
|
|
|
if (gov->governor == GOV_ONDEMAND) {
|
cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
Cpufreq governors like the ondemand governor calculate the load on the CPU
periodically by employing deferrable timers. A deferrable timer won't fire
if the CPU is completely idle (and there are no other timers to be run), in
order to avoid unnecessary wakeups and thus save CPU power.
However, the load calculation logic is agnostic to all this, and this can
lead to the problem described below.
Time (ms) CPU 1
100 Task-A running
110 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
110.5 Task-A running
120 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
125 Task-A went to sleep. With nothing else to do, CPU 1
went completely idle.
200 Task-A woke up and started running again.
200.5 Governor's deferred timer (which was originally programmed
to fire at time 130) fires now. It calculates load for the
time period 120 to 200.5, and finds the load is almost zero.
Hence it decreases the CPU frequency to the minimum.
210 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
So, after the workload woke up and started running, the frequency was suddenly
dropped to absolute minimum, and after that, there was an unnecessary delay of
10ms (sampling period) to increase the CPU frequency back to a reasonable value.
And this pattern repeats for every wake-up-from-cpu-idle for that workload.
This can be quite undesirable for latency- or response-time sensitive bursty
workloads. So we need to fix the governor's logic to detect such wake-up-from-
cpu-idle scenarios and start the workload at a reasonably high CPU frequency.
One extreme solution would be to fake a load of 100% in such scenarios. But
that might lead to undesirable side-effects such as frequency spikes (which
might also need voltage changes) especially if the previous frequency happened
to be very low.
We just want to avoid the stupidity of dropping down the frequency to a minimum
and then enduring a needless (and long) delay before ramping it up back again.
So, let us simply carry forward the previous load - that is, let us just pretend
that the 'load' for the current time-window is the same as the load for the
previous window. That way, the frequency and voltage will continue to be set
to whatever values they were set at previously. This means that bursty workloads
will get a chance to influence the CPU frequency at which they wake up from
cpu-idle, based on their past execution history. Thus, they might be able to
avoid suffering from slow wakeups and long response-times.
However, we should take care not to over-do this. For example, such a "copy
previous load" logic will benefit cases like this: (where # represents busy
and . represents idle)
##########.........#########.........###########...........##########........
but it will be detrimental in cases like the one shown below, because it will
retain the high frequency (copied from the previous interval) even in a mostly
idle system:
##########.........#.................#.....................#...............
(i.e., the workload finished and the remaining tasks are such that their busy
periods are smaller than the sampling interval, which causes the timer to
always get deferred. So, this will make the copy-previous-load logic copy
the initial high load to subsequent idle periods over and over again, thus
keeping the frequency high unnecessarily).
So, we modify this copy-previous-load logic such that it is used only once
upon every wakeup-from-idle. Thus if we have 2 consecutive idle periods, the
previous load won't get blindly copied over; cpufreq will freshly evaluate the
load in the second idle interval, thus ensuring that the system comes back to
its normal state.
[ The right way to solve this whole problem is to teach the CPU frequency
governors to also track load on a per-task basis, not just a per-CPU basis,
and then use both the data sources intelligently to set the appropriate
frequency on the CPUs. But that involves redesigning the cpufreq subsystem,
so this patch should make the situation bearable until then. ]
Experimental results:
+-------------------+
I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in
between its execution such that its total utilization can be a user-defined
value, say 10% or 20% (higher the utilization specified, lesser the amount of
sleeps injected). This ebizzy was run with a single-thread, tied to CPU 8.
Behavior observed with tracing (sample taken from 40% utilization runs):
------------------------------------------------------------------------
Without patch:
~~~~~~~~~~~~~~
kworker/8:2-12137 416.335742: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.335744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.345741: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.345744: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.345746: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.355738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
<...>-40753 416.402202: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 416.502130: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40753 416.505738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.505739: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.505741: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.515739: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.515742: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.515744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
Observation: Ebizzy went idle at 416.402202, and started running again at
416.502130. But cpufreq noticed the long idle period, and dropped the frequency
at 416.505739, only to increase it back again at 416.515742, realizing that the
workload is in-fact CPU bound. Thus ebizzy needlessly ran at the lowest frequency
for almost 13 milliseconds (almost 1 full sample period), and this pattern
repeats on every sleep-wakeup. This could hurt latency-sensitive workloads quite
a lot.
With patch:
~~~~~~~~~~~
kworker/8:2-29802 464.832535: cpu_frequency: state=2061000 cpu_id=8
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 464.962538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.972533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 464.972536: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-29802 464.972538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.982531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 465.022533: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.032531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.032532: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.035797: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 465.240178: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40738 465.242533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.242535: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.252531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
Observation: Ebizzy went idle at 465.035797, and started running again at
465.240178. Since ebizzy was the only real workload running on this CPU,
cpufreq retained the frequency at 4.1Ghz throughout the run of ebizzy, no
matter how many times ebizzy slept and woke-up in-between. Thus, ebizzy
got the 10ms worth of 4.1 Ghz benefit during every sleep-wakeup (as compared
to the run without the patch) and this boost gave a modest improvement in total
throughput, as shown below.
Sleeping-ebizzy records-per-second:
-----------------------------------
Utilization Without patch With patch Difference (Absolute and % values)
10% 274767 277046 + 2279 (+0.829%)
20% 543429 553484 + 10055 (+1.850%)
40% 1090744 1107959 + 17215 (+1.578%)
60% 1634908 1662018 + 27110 (+1.658%)
A rudimentary and somewhat approximately latency-sensitive workload such as
sleeping-ebizzy itself showed a consistent, noticeable performance improvement
with this patch. Hence, workloads that are truly latency-sensitive will benefit
quite a bit from this change. Moreover, this is an overall win-win since this
patch does not hurt power-savings at all (because, this patch does not reduce
the idle time or idle residency; and the high frequency of the CPU when it goes
to cpu-idle does not affect/hurt the power-savings of deep idle states).
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-08 04:41:43 +08:00
|
|
|
struct od_cpu_dbs_info_s *od_dbs_info =
|
2016-02-07 23:09:51 +08:00
|
|
|
gov->get_cpu_dbs_info_s(cpu);
|
cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
Cpufreq governors like the ondemand governor calculate the load on the CPU
periodically by employing deferrable timers. A deferrable timer won't fire
if the CPU is completely idle (and there are no other timers to be run), in
order to avoid unnecessary wakeups and thus save CPU power.
However, the load calculation logic is agnostic to all this, and this can
lead to the problem described below.
Time (ms) CPU 1
100 Task-A running
110 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
110.5 Task-A running
120 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
125 Task-A went to sleep. With nothing else to do, CPU 1
went completely idle.
200 Task-A woke up and started running again.
200.5 Governor's deferred timer (which was originally programmed
to fire at time 130) fires now. It calculates load for the
time period 120 to 200.5, and finds the load is almost zero.
Hence it decreases the CPU frequency to the minimum.
210 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
So, after the workload woke up and started running, the frequency was suddenly
dropped to absolute minimum, and after that, there was an unnecessary delay of
10ms (sampling period) to increase the CPU frequency back to a reasonable value.
And this pattern repeats for every wake-up-from-cpu-idle for that workload.
This can be quite undesirable for latency- or response-time sensitive bursty
workloads. So we need to fix the governor's logic to detect such wake-up-from-
cpu-idle scenarios and start the workload at a reasonably high CPU frequency.
One extreme solution would be to fake a load of 100% in such scenarios. But
that might lead to undesirable side-effects such as frequency spikes (which
might also need voltage changes) especially if the previous frequency happened
to be very low.
We just want to avoid the stupidity of dropping down the frequency to a minimum
and then enduring a needless (and long) delay before ramping it up back again.
So, let us simply carry forward the previous load - that is, let us just pretend
that the 'load' for the current time-window is the same as the load for the
previous window. That way, the frequency and voltage will continue to be set
to whatever values they were set at previously. This means that bursty workloads
will get a chance to influence the CPU frequency at which they wake up from
cpu-idle, based on their past execution history. Thus, they might be able to
avoid suffering from slow wakeups and long response-times.
However, we should take care not to over-do this. For example, such a "copy
previous load" logic will benefit cases like this: (where # represents busy
and . represents idle)
##########.........#########.........###########...........##########........
but it will be detrimental in cases like the one shown below, because it will
retain the high frequency (copied from the previous interval) even in a mostly
idle system:
##########.........#.................#.....................#...............
(i.e., the workload finished and the remaining tasks are such that their busy
periods are smaller than the sampling interval, which causes the timer to
always get deferred. So, this will make the copy-previous-load logic copy
the initial high load to subsequent idle periods over and over again, thus
keeping the frequency high unnecessarily).
So, we modify this copy-previous-load logic such that it is used only once
upon every wakeup-from-idle. Thus if we have 2 consecutive idle periods, the
previous load won't get blindly copied over; cpufreq will freshly evaluate the
load in the second idle interval, thus ensuring that the system comes back to
its normal state.
[ The right way to solve this whole problem is to teach the CPU frequency
governors to also track load on a per-task basis, not just a per-CPU basis,
and then use both the data sources intelligently to set the appropriate
frequency on the CPUs. But that involves redesigning the cpufreq subsystem,
so this patch should make the situation bearable until then. ]
Experimental results:
+-------------------+
I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in
between its execution such that its total utilization can be a user-defined
value, say 10% or 20% (higher the utilization specified, lesser the amount of
sleeps injected). This ebizzy was run with a single-thread, tied to CPU 8.
Behavior observed with tracing (sample taken from 40% utilization runs):
------------------------------------------------------------------------
Without patch:
~~~~~~~~~~~~~~
kworker/8:2-12137 416.335742: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.335744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.345741: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.345744: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.345746: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.355738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
<...>-40753 416.402202: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 416.502130: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40753 416.505738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.505739: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.505741: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.515739: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.515742: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.515744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
Observation: Ebizzy went idle at 416.402202, and started running again at
416.502130. But cpufreq noticed the long idle period, and dropped the frequency
at 416.505739, only to increase it back again at 416.515742, realizing that the
workload is in-fact CPU bound. Thus ebizzy needlessly ran at the lowest frequency
for almost 13 milliseconds (almost 1 full sample period), and this pattern
repeats on every sleep-wakeup. This could hurt latency-sensitive workloads quite
a lot.
With patch:
~~~~~~~~~~~
kworker/8:2-29802 464.832535: cpu_frequency: state=2061000 cpu_id=8
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 464.962538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.972533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 464.972536: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-29802 464.972538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.982531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 465.022533: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.032531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.032532: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.035797: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 465.240178: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40738 465.242533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.242535: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.252531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
Observation: Ebizzy went idle at 465.035797, and started running again at
465.240178. Since ebizzy was the only real workload running on this CPU,
cpufreq retained the frequency at 4.1Ghz throughout the run of ebizzy, no
matter how many times ebizzy slept and woke-up in-between. Thus, ebizzy
got the 10ms worth of 4.1 Ghz benefit during every sleep-wakeup (as compared
to the run without the patch) and this boost gave a modest improvement in total
throughput, as shown below.
Sleeping-ebizzy records-per-second:
-----------------------------------
Utilization Without patch With patch Difference (Absolute and % values)
10% 274767 277046 + 2279 (+0.829%)
20% 543429 553484 + 10055 (+1.850%)
40% 1090744 1107959 + 17215 (+1.578%)
60% 1634908 1662018 + 27110 (+1.658%)
A rudimentary and somewhat approximately latency-sensitive workload such as
sleeping-ebizzy itself showed a consistent, noticeable performance improvement
with this patch. Hence, workloads that are truly latency-sensitive will benefit
quite a bit from this change. Moreover, this is an overall win-win since this
patch does not hurt power-savings at all (because, this patch does not reduce
the idle time or idle residency; and the high frequency of the CPU when it goes
to cpu-idle does not affect/hurt the power-savings of deep idle states).
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-08 04:41:43 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Sometimes, the ondemand governor uses an additional
|
|
|
|
* multiplier to give long delays. So apply this multiplier to
|
|
|
|
* the 'sampling_rate', so as to keep the wake-up-from-idle
|
|
|
|
* detection logic a bit conservative.
|
|
|
|
*/
|
|
|
|
sampling_rate *= od_dbs_info->rate_mult;
|
|
|
|
|
|
|
|
}
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2013-06-06 00:01:25 +08:00
|
|
|
/* Get Absolute Load */
|
2012-10-26 06:47:42 +08:00
|
|
|
for_each_cpu(j, policy->cpus) {
|
2015-06-19 19:48:03 +08:00
|
|
|
struct cpu_dbs_info *j_cdbs;
|
2013-03-01 00:57:32 +08:00
|
|
|
u64 cur_wall_time, cur_idle_time;
|
|
|
|
unsigned int idle_time, wall_time;
|
2012-10-26 06:47:42 +08:00
|
|
|
unsigned int load;
|
2013-03-01 00:57:32 +08:00
|
|
|
int io_busy = 0;
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2016-02-07 23:09:51 +08:00
|
|
|
j_cdbs = gov->get_cpu_cdbs(j);
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2013-03-01 00:57:32 +08:00
|
|
|
/*
|
|
|
|
* For the purpose of ondemand, waiting for disk IO is
|
|
|
|
* an indication that you're performance critical, and
|
|
|
|
* not that the system is actually idle. So do not add
|
|
|
|
* the iowait time to the cpu idle time.
|
|
|
|
*/
|
2016-02-07 23:09:51 +08:00
|
|
|
if (gov->governor == GOV_ONDEMAND)
|
2013-03-01 00:57:32 +08:00
|
|
|
io_busy = od_tuners->io_is_busy;
|
|
|
|
cur_idle_time = get_cpu_idle_time(j, &cur_wall_time, io_busy);
|
2012-10-26 06:47:42 +08:00
|
|
|
|
|
|
|
wall_time = (unsigned int)
|
|
|
|
(cur_wall_time - j_cdbs->prev_cpu_wall);
|
|
|
|
j_cdbs->prev_cpu_wall = cur_wall_time;
|
|
|
|
|
cpufreq: governor: Fix negative idle_time when configured with CONFIG_HZ_PERIODIC
It is reported that, with CONFIG_HZ_PERIODIC=y cpu stays at the
lowest frequency even if the usage goes to 100%, neither ondemand
nor conservative governor works, however performance and
userspace work as expected. If set with CONFIG_NO_HZ_FULL=y,
everything goes well.
This problem is caused by improper calculation of the idle_time
when the load is extremely high(near 100%). Firstly, cpufreq_governor
uses get_cpu_idle_time to get the total idle time for specific cpu, then:
1.If the system is configured with CONFIG_NO_HZ_FULL, the idle time is
returned by ktime_get, which is always increasing, it's OK.
2.However, if the system is configured with CONFIG_HZ_PERIODIC,
get_cpu_idle_time might not guarantee to be always increasing,
because it will leverage get_cpu_idle_time_jiffy to calculate the
idle_time, consider the following scenario:
At T1:
idle_tick_1 = total_tick_1 - user_tick_1
sample period(80ms)...
At T2: ( T2 = T1 + 80ms):
idle_tick_2 = total_tick_2 - user_tick_2
Currently the algorithm is using (idle_tick_2 - idle_tick_1) to
get the delta idle_time during the past sample period, however
it CAN NOT guarantee that idle_tick_2 >= idle_tick_1, especially
when cpu load is high.
(Yes, total_tick_2 >= total_tick_1, and user_tick_2 >= user_tick_1,
but how about idle_tick_2 and idle_tick_1? No guarantee.)
So governor might get a negative value of idle_time during the past
sample period, which might mislead the system that the idle time is
very big(converted to unsigned int), and the busy time is nearly zero,
which causes the governor to always choose the lowest cpufreq,
then cause this problem.
In theory there are two solutions:
1.The logic should not rely on the idle tick during every sample period,
but be based on the busy tick directly, as this is how 'top' is
implemented.
2.Or the logic must make sure that the idle_time is strictly increasing
during each sample period, then there would be no negative idle_time
anymore. This solution requires minimum modification to current code
and this patch uses method 2.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=69821
Reported-by: Jan Fikar <j.fikar@gmail.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-16 12:20:29 +08:00
|
|
|
if (cur_idle_time < j_cdbs->prev_cpu_idle)
|
|
|
|
cur_idle_time = j_cdbs->prev_cpu_idle;
|
|
|
|
|
2012-10-26 06:47:42 +08:00
|
|
|
idle_time = (unsigned int)
|
|
|
|
(cur_idle_time - j_cdbs->prev_cpu_idle);
|
|
|
|
j_cdbs->prev_cpu_idle = cur_idle_time;
|
|
|
|
|
|
|
|
if (ignore_nice) {
|
2016-02-07 23:24:26 +08:00
|
|
|
struct cpu_dbs_info *cdbs = gov->get_cpu_cdbs(cpu);
|
2012-10-26 06:47:42 +08:00
|
|
|
u64 cur_nice;
|
|
|
|
unsigned long cur_nice_jiffies;
|
|
|
|
|
|
|
|
cur_nice = kcpustat_cpu(j).cpustat[CPUTIME_NICE] -
|
|
|
|
cdbs->prev_cpu_nice;
|
|
|
|
/*
|
|
|
|
* Assumption: nice time between sampling periods will
|
|
|
|
* be less than 2^32 jiffies for 32 bit sys
|
|
|
|
*/
|
|
|
|
cur_nice_jiffies = (unsigned long)
|
|
|
|
cputime64_to_jiffies64(cur_nice);
|
|
|
|
|
|
|
|
cdbs->prev_cpu_nice =
|
|
|
|
kcpustat_cpu(j).cpustat[CPUTIME_NICE];
|
|
|
|
idle_time += jiffies_to_usecs(cur_nice_jiffies);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (unlikely(!wall_time || wall_time < idle_time))
|
|
|
|
continue;
|
|
|
|
|
cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
Cpufreq governors like the ondemand governor calculate the load on the CPU
periodically by employing deferrable timers. A deferrable timer won't fire
if the CPU is completely idle (and there are no other timers to be run), in
order to avoid unnecessary wakeups and thus save CPU power.
However, the load calculation logic is agnostic to all this, and this can
lead to the problem described below.
Time (ms) CPU 1
100 Task-A running
110 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
110.5 Task-A running
120 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
125 Task-A went to sleep. With nothing else to do, CPU 1
went completely idle.
200 Task-A woke up and started running again.
200.5 Governor's deferred timer (which was originally programmed
to fire at time 130) fires now. It calculates load for the
time period 120 to 200.5, and finds the load is almost zero.
Hence it decreases the CPU frequency to the minimum.
210 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
So, after the workload woke up and started running, the frequency was suddenly
dropped to absolute minimum, and after that, there was an unnecessary delay of
10ms (sampling period) to increase the CPU frequency back to a reasonable value.
And this pattern repeats for every wake-up-from-cpu-idle for that workload.
This can be quite undesirable for latency- or response-time sensitive bursty
workloads. So we need to fix the governor's logic to detect such wake-up-from-
cpu-idle scenarios and start the workload at a reasonably high CPU frequency.
One extreme solution would be to fake a load of 100% in such scenarios. But
that might lead to undesirable side-effects such as frequency spikes (which
might also need voltage changes) especially if the previous frequency happened
to be very low.
We just want to avoid the stupidity of dropping down the frequency to a minimum
and then enduring a needless (and long) delay before ramping it up back again.
So, let us simply carry forward the previous load - that is, let us just pretend
that the 'load' for the current time-window is the same as the load for the
previous window. That way, the frequency and voltage will continue to be set
to whatever values they were set at previously. This means that bursty workloads
will get a chance to influence the CPU frequency at which they wake up from
cpu-idle, based on their past execution history. Thus, they might be able to
avoid suffering from slow wakeups and long response-times.
However, we should take care not to over-do this. For example, such a "copy
previous load" logic will benefit cases like this: (where # represents busy
and . represents idle)
##########.........#########.........###########...........##########........
but it will be detrimental in cases like the one shown below, because it will
retain the high frequency (copied from the previous interval) even in a mostly
idle system:
##########.........#.................#.....................#...............
(i.e., the workload finished and the remaining tasks are such that their busy
periods are smaller than the sampling interval, which causes the timer to
always get deferred. So, this will make the copy-previous-load logic copy
the initial high load to subsequent idle periods over and over again, thus
keeping the frequency high unnecessarily).
So, we modify this copy-previous-load logic such that it is used only once
upon every wakeup-from-idle. Thus if we have 2 consecutive idle periods, the
previous load won't get blindly copied over; cpufreq will freshly evaluate the
load in the second idle interval, thus ensuring that the system comes back to
its normal state.
[ The right way to solve this whole problem is to teach the CPU frequency
governors to also track load on a per-task basis, not just a per-CPU basis,
and then use both the data sources intelligently to set the appropriate
frequency on the CPUs. But that involves redesigning the cpufreq subsystem,
so this patch should make the situation bearable until then. ]
Experimental results:
+-------------------+
I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in
between its execution such that its total utilization can be a user-defined
value, say 10% or 20% (higher the utilization specified, lesser the amount of
sleeps injected). This ebizzy was run with a single-thread, tied to CPU 8.
Behavior observed with tracing (sample taken from 40% utilization runs):
------------------------------------------------------------------------
Without patch:
~~~~~~~~~~~~~~
kworker/8:2-12137 416.335742: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.335744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.345741: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.345744: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.345746: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.355738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
<...>-40753 416.402202: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 416.502130: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40753 416.505738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.505739: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.505741: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.515739: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.515742: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.515744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
Observation: Ebizzy went idle at 416.402202, and started running again at
416.502130. But cpufreq noticed the long idle period, and dropped the frequency
at 416.505739, only to increase it back again at 416.515742, realizing that the
workload is in-fact CPU bound. Thus ebizzy needlessly ran at the lowest frequency
for almost 13 milliseconds (almost 1 full sample period), and this pattern
repeats on every sleep-wakeup. This could hurt latency-sensitive workloads quite
a lot.
With patch:
~~~~~~~~~~~
kworker/8:2-29802 464.832535: cpu_frequency: state=2061000 cpu_id=8
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 464.962538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.972533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 464.972536: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-29802 464.972538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.982531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 465.022533: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.032531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.032532: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.035797: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 465.240178: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40738 465.242533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.242535: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.252531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
Observation: Ebizzy went idle at 465.035797, and started running again at
465.240178. Since ebizzy was the only real workload running on this CPU,
cpufreq retained the frequency at 4.1Ghz throughout the run of ebizzy, no
matter how many times ebizzy slept and woke-up in-between. Thus, ebizzy
got the 10ms worth of 4.1 Ghz benefit during every sleep-wakeup (as compared
to the run without the patch) and this boost gave a modest improvement in total
throughput, as shown below.
Sleeping-ebizzy records-per-second:
-----------------------------------
Utilization Without patch With patch Difference (Absolute and % values)
10% 274767 277046 + 2279 (+0.829%)
20% 543429 553484 + 10055 (+1.850%)
40% 1090744 1107959 + 17215 (+1.578%)
60% 1634908 1662018 + 27110 (+1.658%)
A rudimentary and somewhat approximately latency-sensitive workload such as
sleeping-ebizzy itself showed a consistent, noticeable performance improvement
with this patch. Hence, workloads that are truly latency-sensitive will benefit
quite a bit from this change. Moreover, this is an overall win-win since this
patch does not hurt power-savings at all (because, this patch does not reduce
the idle time or idle residency; and the high frequency of the CPU when it goes
to cpu-idle does not affect/hurt the power-savings of deep idle states).
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-08 04:41:43 +08:00
|
|
|
/*
|
|
|
|
* If the CPU had gone completely idle, and a task just woke up
|
|
|
|
* on this CPU now, it would be unfair to calculate 'load' the
|
|
|
|
* usual way for this elapsed time-window, because it will show
|
|
|
|
* near-zero load, irrespective of how CPU intensive that task
|
|
|
|
* actually is. This is undesirable for latency-sensitive bursty
|
|
|
|
* workloads.
|
|
|
|
*
|
|
|
|
* To avoid this, we reuse the 'load' from the previous
|
|
|
|
* time-window and give this task a chance to start with a
|
|
|
|
* reasonably high CPU frequency. (However, we shouldn't over-do
|
|
|
|
* this copy, lest we get stuck at a high load (high frequency)
|
|
|
|
* for too long, even when the current system load has actually
|
|
|
|
* dropped down. So we perform the copy only once, upon the
|
|
|
|
* first wake-up from idle.)
|
|
|
|
*
|
2016-02-10 23:53:50 +08:00
|
|
|
* Detecting this situation is easy: the governor's utilization
|
|
|
|
* update handler would not have run during CPU-idle periods.
|
|
|
|
* Hence, an unusually large 'wall_time' (as compared to the
|
|
|
|
* sampling rate) indicates this scenario.
|
2014-06-09 16:51:24 +08:00
|
|
|
*
|
|
|
|
* prev_load can be zero in two cases and we must recalculate it
|
|
|
|
* for both cases:
|
|
|
|
* - during long idle intervals
|
|
|
|
* - explicitly set to zero
|
cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
Cpufreq governors like the ondemand governor calculate the load on the CPU
periodically by employing deferrable timers. A deferrable timer won't fire
if the CPU is completely idle (and there are no other timers to be run), in
order to avoid unnecessary wakeups and thus save CPU power.
However, the load calculation logic is agnostic to all this, and this can
lead to the problem described below.
Time (ms) CPU 1
100 Task-A running
110 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
110.5 Task-A running
120 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
125 Task-A went to sleep. With nothing else to do, CPU 1
went completely idle.
200 Task-A woke up and started running again.
200.5 Governor's deferred timer (which was originally programmed
to fire at time 130) fires now. It calculates load for the
time period 120 to 200.5, and finds the load is almost zero.
Hence it decreases the CPU frequency to the minimum.
210 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
So, after the workload woke up and started running, the frequency was suddenly
dropped to absolute minimum, and after that, there was an unnecessary delay of
10ms (sampling period) to increase the CPU frequency back to a reasonable value.
And this pattern repeats for every wake-up-from-cpu-idle for that workload.
This can be quite undesirable for latency- or response-time sensitive bursty
workloads. So we need to fix the governor's logic to detect such wake-up-from-
cpu-idle scenarios and start the workload at a reasonably high CPU frequency.
One extreme solution would be to fake a load of 100% in such scenarios. But
that might lead to undesirable side-effects such as frequency spikes (which
might also need voltage changes) especially if the previous frequency happened
to be very low.
We just want to avoid the stupidity of dropping down the frequency to a minimum
and then enduring a needless (and long) delay before ramping it up back again.
So, let us simply carry forward the previous load - that is, let us just pretend
that the 'load' for the current time-window is the same as the load for the
previous window. That way, the frequency and voltage will continue to be set
to whatever values they were set at previously. This means that bursty workloads
will get a chance to influence the CPU frequency at which they wake up from
cpu-idle, based on their past execution history. Thus, they might be able to
avoid suffering from slow wakeups and long response-times.
However, we should take care not to over-do this. For example, such a "copy
previous load" logic will benefit cases like this: (where # represents busy
and . represents idle)
##########.........#########.........###########...........##########........
but it will be detrimental in cases like the one shown below, because it will
retain the high frequency (copied from the previous interval) even in a mostly
idle system:
##########.........#.................#.....................#...............
(i.e., the workload finished and the remaining tasks are such that their busy
periods are smaller than the sampling interval, which causes the timer to
always get deferred. So, this will make the copy-previous-load logic copy
the initial high load to subsequent idle periods over and over again, thus
keeping the frequency high unnecessarily).
So, we modify this copy-previous-load logic such that it is used only once
upon every wakeup-from-idle. Thus if we have 2 consecutive idle periods, the
previous load won't get blindly copied over; cpufreq will freshly evaluate the
load in the second idle interval, thus ensuring that the system comes back to
its normal state.
[ The right way to solve this whole problem is to teach the CPU frequency
governors to also track load on a per-task basis, not just a per-CPU basis,
and then use both the data sources intelligently to set the appropriate
frequency on the CPUs. But that involves redesigning the cpufreq subsystem,
so this patch should make the situation bearable until then. ]
Experimental results:
+-------------------+
I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in
between its execution such that its total utilization can be a user-defined
value, say 10% or 20% (higher the utilization specified, lesser the amount of
sleeps injected). This ebizzy was run with a single-thread, tied to CPU 8.
Behavior observed with tracing (sample taken from 40% utilization runs):
------------------------------------------------------------------------
Without patch:
~~~~~~~~~~~~~~
kworker/8:2-12137 416.335742: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.335744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.345741: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.345744: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.345746: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.355738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
<...>-40753 416.402202: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 416.502130: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40753 416.505738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.505739: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.505741: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.515739: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.515742: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.515744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
Observation: Ebizzy went idle at 416.402202, and started running again at
416.502130. But cpufreq noticed the long idle period, and dropped the frequency
at 416.505739, only to increase it back again at 416.515742, realizing that the
workload is in-fact CPU bound. Thus ebizzy needlessly ran at the lowest frequency
for almost 13 milliseconds (almost 1 full sample period), and this pattern
repeats on every sleep-wakeup. This could hurt latency-sensitive workloads quite
a lot.
With patch:
~~~~~~~~~~~
kworker/8:2-29802 464.832535: cpu_frequency: state=2061000 cpu_id=8
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 464.962538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.972533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 464.972536: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-29802 464.972538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.982531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 465.022533: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.032531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.032532: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.035797: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 465.240178: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40738 465.242533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.242535: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.252531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
Observation: Ebizzy went idle at 465.035797, and started running again at
465.240178. Since ebizzy was the only real workload running on this CPU,
cpufreq retained the frequency at 4.1Ghz throughout the run of ebizzy, no
matter how many times ebizzy slept and woke-up in-between. Thus, ebizzy
got the 10ms worth of 4.1 Ghz benefit during every sleep-wakeup (as compared
to the run without the patch) and this boost gave a modest improvement in total
throughput, as shown below.
Sleeping-ebizzy records-per-second:
-----------------------------------
Utilization Without patch With patch Difference (Absolute and % values)
10% 274767 277046 + 2279 (+0.829%)
20% 543429 553484 + 10055 (+1.850%)
40% 1090744 1107959 + 17215 (+1.578%)
60% 1634908 1662018 + 27110 (+1.658%)
A rudimentary and somewhat approximately latency-sensitive workload such as
sleeping-ebizzy itself showed a consistent, noticeable performance improvement
with this patch. Hence, workloads that are truly latency-sensitive will benefit
quite a bit from this change. Moreover, this is an overall win-win since this
patch does not hurt power-savings at all (because, this patch does not reduce
the idle time or idle residency; and the high frequency of the CPU when it goes
to cpu-idle does not affect/hurt the power-savings of deep idle states).
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-08 04:41:43 +08:00
|
|
|
*/
|
2014-06-09 16:51:24 +08:00
|
|
|
if (unlikely(wall_time > (2 * sampling_rate) &&
|
|
|
|
j_cdbs->prev_load)) {
|
cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
Cpufreq governors like the ondemand governor calculate the load on the CPU
periodically by employing deferrable timers. A deferrable timer won't fire
if the CPU is completely idle (and there are no other timers to be run), in
order to avoid unnecessary wakeups and thus save CPU power.
However, the load calculation logic is agnostic to all this, and this can
lead to the problem described below.
Time (ms) CPU 1
100 Task-A running
110 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
110.5 Task-A running
120 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
125 Task-A went to sleep. With nothing else to do, CPU 1
went completely idle.
200 Task-A woke up and started running again.
200.5 Governor's deferred timer (which was originally programmed
to fire at time 130) fires now. It calculates load for the
time period 120 to 200.5, and finds the load is almost zero.
Hence it decreases the CPU frequency to the minimum.
210 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
So, after the workload woke up and started running, the frequency was suddenly
dropped to absolute minimum, and after that, there was an unnecessary delay of
10ms (sampling period) to increase the CPU frequency back to a reasonable value.
And this pattern repeats for every wake-up-from-cpu-idle for that workload.
This can be quite undesirable for latency- or response-time sensitive bursty
workloads. So we need to fix the governor's logic to detect such wake-up-from-
cpu-idle scenarios and start the workload at a reasonably high CPU frequency.
One extreme solution would be to fake a load of 100% in such scenarios. But
that might lead to undesirable side-effects such as frequency spikes (which
might also need voltage changes) especially if the previous frequency happened
to be very low.
We just want to avoid the stupidity of dropping down the frequency to a minimum
and then enduring a needless (and long) delay before ramping it up back again.
So, let us simply carry forward the previous load - that is, let us just pretend
that the 'load' for the current time-window is the same as the load for the
previous window. That way, the frequency and voltage will continue to be set
to whatever values they were set at previously. This means that bursty workloads
will get a chance to influence the CPU frequency at which they wake up from
cpu-idle, based on their past execution history. Thus, they might be able to
avoid suffering from slow wakeups and long response-times.
However, we should take care not to over-do this. For example, such a "copy
previous load" logic will benefit cases like this: (where # represents busy
and . represents idle)
##########.........#########.........###########...........##########........
but it will be detrimental in cases like the one shown below, because it will
retain the high frequency (copied from the previous interval) even in a mostly
idle system:
##########.........#.................#.....................#...............
(i.e., the workload finished and the remaining tasks are such that their busy
periods are smaller than the sampling interval, which causes the timer to
always get deferred. So, this will make the copy-previous-load logic copy
the initial high load to subsequent idle periods over and over again, thus
keeping the frequency high unnecessarily).
So, we modify this copy-previous-load logic such that it is used only once
upon every wakeup-from-idle. Thus if we have 2 consecutive idle periods, the
previous load won't get blindly copied over; cpufreq will freshly evaluate the
load in the second idle interval, thus ensuring that the system comes back to
its normal state.
[ The right way to solve this whole problem is to teach the CPU frequency
governors to also track load on a per-task basis, not just a per-CPU basis,
and then use both the data sources intelligently to set the appropriate
frequency on the CPUs. But that involves redesigning the cpufreq subsystem,
so this patch should make the situation bearable until then. ]
Experimental results:
+-------------------+
I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in
between its execution such that its total utilization can be a user-defined
value, say 10% or 20% (higher the utilization specified, lesser the amount of
sleeps injected). This ebizzy was run with a single-thread, tied to CPU 8.
Behavior observed with tracing (sample taken from 40% utilization runs):
------------------------------------------------------------------------
Without patch:
~~~~~~~~~~~~~~
kworker/8:2-12137 416.335742: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.335744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.345741: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.345744: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.345746: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.355738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
<...>-40753 416.402202: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 416.502130: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40753 416.505738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.505739: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.505741: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.515739: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.515742: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.515744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
Observation: Ebizzy went idle at 416.402202, and started running again at
416.502130. But cpufreq noticed the long idle period, and dropped the frequency
at 416.505739, only to increase it back again at 416.515742, realizing that the
workload is in-fact CPU bound. Thus ebizzy needlessly ran at the lowest frequency
for almost 13 milliseconds (almost 1 full sample period), and this pattern
repeats on every sleep-wakeup. This could hurt latency-sensitive workloads quite
a lot.
With patch:
~~~~~~~~~~~
kworker/8:2-29802 464.832535: cpu_frequency: state=2061000 cpu_id=8
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 464.962538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.972533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 464.972536: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-29802 464.972538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.982531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 465.022533: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.032531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.032532: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.035797: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 465.240178: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40738 465.242533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.242535: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.252531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
Observation: Ebizzy went idle at 465.035797, and started running again at
465.240178. Since ebizzy was the only real workload running on this CPU,
cpufreq retained the frequency at 4.1Ghz throughout the run of ebizzy, no
matter how many times ebizzy slept and woke-up in-between. Thus, ebizzy
got the 10ms worth of 4.1 Ghz benefit during every sleep-wakeup (as compared
to the run without the patch) and this boost gave a modest improvement in total
throughput, as shown below.
Sleeping-ebizzy records-per-second:
-----------------------------------
Utilization Without patch With patch Difference (Absolute and % values)
10% 274767 277046 + 2279 (+0.829%)
20% 543429 553484 + 10055 (+1.850%)
40% 1090744 1107959 + 17215 (+1.578%)
60% 1634908 1662018 + 27110 (+1.658%)
A rudimentary and somewhat approximately latency-sensitive workload such as
sleeping-ebizzy itself showed a consistent, noticeable performance improvement
with this patch. Hence, workloads that are truly latency-sensitive will benefit
quite a bit from this change. Moreover, this is an overall win-win since this
patch does not hurt power-savings at all (because, this patch does not reduce
the idle time or idle residency; and the high frequency of the CPU when it goes
to cpu-idle does not affect/hurt the power-savings of deep idle states).
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-08 04:41:43 +08:00
|
|
|
load = j_cdbs->prev_load;
|
2014-06-09 16:51:24 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Perform a destructive copy, to ensure that we copy
|
|
|
|
* the previous load only once, upon the first wake-up
|
|
|
|
* from idle.
|
|
|
|
*/
|
|
|
|
j_cdbs->prev_load = 0;
|
cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
Cpufreq governors like the ondemand governor calculate the load on the CPU
periodically by employing deferrable timers. A deferrable timer won't fire
if the CPU is completely idle (and there are no other timers to be run), in
order to avoid unnecessary wakeups and thus save CPU power.
However, the load calculation logic is agnostic to all this, and this can
lead to the problem described below.
Time (ms) CPU 1
100 Task-A running
110 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
110.5 Task-A running
120 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
125 Task-A went to sleep. With nothing else to do, CPU 1
went completely idle.
200 Task-A woke up and started running again.
200.5 Governor's deferred timer (which was originally programmed
to fire at time 130) fires now. It calculates load for the
time period 120 to 200.5, and finds the load is almost zero.
Hence it decreases the CPU frequency to the minimum.
210 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
So, after the workload woke up and started running, the frequency was suddenly
dropped to absolute minimum, and after that, there was an unnecessary delay of
10ms (sampling period) to increase the CPU frequency back to a reasonable value.
And this pattern repeats for every wake-up-from-cpu-idle for that workload.
This can be quite undesirable for latency- or response-time sensitive bursty
workloads. So we need to fix the governor's logic to detect such wake-up-from-
cpu-idle scenarios and start the workload at a reasonably high CPU frequency.
One extreme solution would be to fake a load of 100% in such scenarios. But
that might lead to undesirable side-effects such as frequency spikes (which
might also need voltage changes) especially if the previous frequency happened
to be very low.
We just want to avoid the stupidity of dropping down the frequency to a minimum
and then enduring a needless (and long) delay before ramping it up back again.
So, let us simply carry forward the previous load - that is, let us just pretend
that the 'load' for the current time-window is the same as the load for the
previous window. That way, the frequency and voltage will continue to be set
to whatever values they were set at previously. This means that bursty workloads
will get a chance to influence the CPU frequency at which they wake up from
cpu-idle, based on their past execution history. Thus, they might be able to
avoid suffering from slow wakeups and long response-times.
However, we should take care not to over-do this. For example, such a "copy
previous load" logic will benefit cases like this: (where # represents busy
and . represents idle)
##########.........#########.........###########...........##########........
but it will be detrimental in cases like the one shown below, because it will
retain the high frequency (copied from the previous interval) even in a mostly
idle system:
##########.........#.................#.....................#...............
(i.e., the workload finished and the remaining tasks are such that their busy
periods are smaller than the sampling interval, which causes the timer to
always get deferred. So, this will make the copy-previous-load logic copy
the initial high load to subsequent idle periods over and over again, thus
keeping the frequency high unnecessarily).
So, we modify this copy-previous-load logic such that it is used only once
upon every wakeup-from-idle. Thus if we have 2 consecutive idle periods, the
previous load won't get blindly copied over; cpufreq will freshly evaluate the
load in the second idle interval, thus ensuring that the system comes back to
its normal state.
[ The right way to solve this whole problem is to teach the CPU frequency
governors to also track load on a per-task basis, not just a per-CPU basis,
and then use both the data sources intelligently to set the appropriate
frequency on the CPUs. But that involves redesigning the cpufreq subsystem,
so this patch should make the situation bearable until then. ]
Experimental results:
+-------------------+
I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in
between its execution such that its total utilization can be a user-defined
value, say 10% or 20% (higher the utilization specified, lesser the amount of
sleeps injected). This ebizzy was run with a single-thread, tied to CPU 8.
Behavior observed with tracing (sample taken from 40% utilization runs):
------------------------------------------------------------------------
Without patch:
~~~~~~~~~~~~~~
kworker/8:2-12137 416.335742: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.335744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.345741: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.345744: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.345746: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.355738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
<...>-40753 416.402202: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 416.502130: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40753 416.505738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.505739: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.505741: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.515739: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.515742: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.515744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
Observation: Ebizzy went idle at 416.402202, and started running again at
416.502130. But cpufreq noticed the long idle period, and dropped the frequency
at 416.505739, only to increase it back again at 416.515742, realizing that the
workload is in-fact CPU bound. Thus ebizzy needlessly ran at the lowest frequency
for almost 13 milliseconds (almost 1 full sample period), and this pattern
repeats on every sleep-wakeup. This could hurt latency-sensitive workloads quite
a lot.
With patch:
~~~~~~~~~~~
kworker/8:2-29802 464.832535: cpu_frequency: state=2061000 cpu_id=8
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 464.962538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.972533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 464.972536: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-29802 464.972538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.982531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 465.022533: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.032531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.032532: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.035797: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 465.240178: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40738 465.242533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.242535: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.252531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
Observation: Ebizzy went idle at 465.035797, and started running again at
465.240178. Since ebizzy was the only real workload running on this CPU,
cpufreq retained the frequency at 4.1Ghz throughout the run of ebizzy, no
matter how many times ebizzy slept and woke-up in-between. Thus, ebizzy
got the 10ms worth of 4.1 Ghz benefit during every sleep-wakeup (as compared
to the run without the patch) and this boost gave a modest improvement in total
throughput, as shown below.
Sleeping-ebizzy records-per-second:
-----------------------------------
Utilization Without patch With patch Difference (Absolute and % values)
10% 274767 277046 + 2279 (+0.829%)
20% 543429 553484 + 10055 (+1.850%)
40% 1090744 1107959 + 17215 (+1.578%)
60% 1634908 1662018 + 27110 (+1.658%)
A rudimentary and somewhat approximately latency-sensitive workload such as
sleeping-ebizzy itself showed a consistent, noticeable performance improvement
with this patch. Hence, workloads that are truly latency-sensitive will benefit
quite a bit from this change. Moreover, this is an overall win-win since this
patch does not hurt power-savings at all (because, this patch does not reduce
the idle time or idle residency; and the high frequency of the CPU when it goes
to cpu-idle does not affect/hurt the power-savings of deep idle states).
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-08 04:41:43 +08:00
|
|
|
} else {
|
|
|
|
load = 100 * (wall_time - idle_time) / wall_time;
|
|
|
|
j_cdbs->prev_load = load;
|
|
|
|
}
|
2012-10-26 06:47:42 +08:00
|
|
|
|
|
|
|
if (load > max_load)
|
|
|
|
max_load = load;
|
|
|
|
}
|
|
|
|
|
2016-02-07 23:09:51 +08:00
|
|
|
gov->gov_check_cpu(cpu, max_load);
|
2012-10-26 06:47:42 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dbs_check_cpu);
|
|
|
|
|
2016-02-11 00:07:44 +08:00
|
|
|
void gov_set_update_util(struct policy_dbs_info *policy_dbs,
|
2016-02-10 23:53:50 +08:00
|
|
|
unsigned int delay_us)
|
2012-10-26 06:47:42 +08:00
|
|
|
{
|
2016-02-11 00:07:44 +08:00
|
|
|
struct cpufreq_policy *policy = policy_dbs->policy;
|
2016-02-07 23:09:51 +08:00
|
|
|
struct dbs_governor *gov = dbs_governor_of(policy);
|
2015-12-09 10:04:42 +08:00
|
|
|
int cpu;
|
2013-02-27 14:54:03 +08:00
|
|
|
|
2016-02-11 00:07:44 +08:00
|
|
|
gov_update_sample_delay(policy_dbs, delay_us);
|
|
|
|
policy_dbs->last_sample_time = 0;
|
2016-02-10 23:53:50 +08:00
|
|
|
|
2015-12-09 10:04:42 +08:00
|
|
|
for_each_cpu(cpu, policy->cpus) {
|
2016-02-07 23:09:51 +08:00
|
|
|
struct cpu_dbs_info *cdbs = gov->get_cpu_cdbs(cpu);
|
2016-02-10 23:53:50 +08:00
|
|
|
|
|
|
|
cpufreq_set_update_util_data(cpu, &cdbs->update_util);
|
2013-02-27 14:54:03 +08:00
|
|
|
}
|
|
|
|
}
|
2016-02-10 23:53:50 +08:00
|
|
|
EXPORT_SYMBOL_GPL(gov_set_update_util);
|
2013-02-27 14:54:03 +08:00
|
|
|
|
2016-02-10 23:53:50 +08:00
|
|
|
static inline void gov_clear_update_util(struct cpufreq_policy *policy)
|
2013-02-27 14:54:03 +08:00
|
|
|
{
|
|
|
|
int i;
|
2013-01-30 21:53:37 +08:00
|
|
|
|
2016-02-10 23:53:50 +08:00
|
|
|
for_each_cpu(i, policy->cpus)
|
|
|
|
cpufreq_set_update_util_data(i, NULL);
|
|
|
|
|
|
|
|
synchronize_rcu();
|
2012-10-26 06:47:42 +08:00
|
|
|
}
|
|
|
|
|
2016-02-11 20:01:14 +08:00
|
|
|
static void gov_cancel_work(struct cpufreq_policy *policy)
|
2015-12-09 10:04:42 +08:00
|
|
|
{
|
2016-02-11 20:01:14 +08:00
|
|
|
struct policy_dbs_info *policy_dbs = policy->governor_data;
|
|
|
|
|
2016-02-11 00:07:44 +08:00
|
|
|
gov_clear_update_util(policy_dbs->policy);
|
|
|
|
irq_work_sync(&policy_dbs->irq_work);
|
|
|
|
cancel_work_sync(&policy_dbs->work);
|
2016-02-09 06:41:10 +08:00
|
|
|
atomic_set(&policy_dbs->work_count, 0);
|
2015-12-09 10:04:42 +08:00
|
|
|
}
|
2015-07-18 14:01:00 +08:00
|
|
|
|
2015-12-09 10:04:42 +08:00
|
|
|
static void dbs_work_handler(struct work_struct *work)
|
2015-07-18 14:01:00 +08:00
|
|
|
{
|
2016-02-11 00:07:44 +08:00
|
|
|
struct policy_dbs_info *policy_dbs;
|
2015-10-29 10:38:38 +08:00
|
|
|
struct cpufreq_policy *policy;
|
2016-02-07 23:09:51 +08:00
|
|
|
struct dbs_governor *gov;
|
2016-02-10 23:53:50 +08:00
|
|
|
unsigned int delay;
|
2015-07-18 14:01:00 +08:00
|
|
|
|
2016-02-11 00:07:44 +08:00
|
|
|
policy_dbs = container_of(work, struct policy_dbs_info, work);
|
|
|
|
policy = policy_dbs->policy;
|
2016-02-07 23:09:51 +08:00
|
|
|
gov = dbs_governor_of(policy);
|
2015-10-29 10:38:38 +08:00
|
|
|
|
2015-12-09 10:04:42 +08:00
|
|
|
/*
|
2016-02-10 23:53:50 +08:00
|
|
|
* Make sure cpufreq_governor_limits() isn't evaluating load or the
|
|
|
|
* ondemand governor isn't updating the sampling rate in parallel.
|
2015-12-09 10:04:42 +08:00
|
|
|
*/
|
2016-02-11 00:07:44 +08:00
|
|
|
mutex_lock(&policy_dbs->timer_mutex);
|
2016-02-07 23:09:51 +08:00
|
|
|
delay = gov->gov_dbs_timer(policy);
|
2016-02-11 00:07:44 +08:00
|
|
|
policy_dbs->sample_delay_ns = jiffies_to_nsecs(delay);
|
|
|
|
mutex_unlock(&policy_dbs->timer_mutex);
|
2015-12-09 10:04:42 +08:00
|
|
|
|
2016-02-10 23:53:50 +08:00
|
|
|
/*
|
|
|
|
* If the atomic operation below is reordered with respect to the
|
|
|
|
* sample delay modification, the utilization update handler may end
|
|
|
|
* up using a stale sample delay value.
|
|
|
|
*/
|
|
|
|
smp_mb__before_atomic();
|
2016-02-09 06:41:10 +08:00
|
|
|
atomic_dec(&policy_dbs->work_count);
|
2016-02-10 23:53:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void dbs_irq_work(struct irq_work *irq_work)
|
|
|
|
{
|
2016-02-11 00:07:44 +08:00
|
|
|
struct policy_dbs_info *policy_dbs;
|
2015-12-09 10:04:42 +08:00
|
|
|
|
2016-02-11 00:07:44 +08:00
|
|
|
policy_dbs = container_of(irq_work, struct policy_dbs_info, irq_work);
|
|
|
|
schedule_work(&policy_dbs->work);
|
2015-12-09 10:04:42 +08:00
|
|
|
}
|
|
|
|
|
2016-02-10 23:53:50 +08:00
|
|
|
static void dbs_update_util_handler(struct update_util_data *data, u64 time,
|
|
|
|
unsigned long util, unsigned long max)
|
|
|
|
{
|
|
|
|
struct cpu_dbs_info *cdbs = container_of(data, struct cpu_dbs_info, update_util);
|
2016-02-11 00:07:44 +08:00
|
|
|
struct policy_dbs_info *policy_dbs = cdbs->policy_dbs;
|
2015-12-09 10:04:42 +08:00
|
|
|
|
|
|
|
/*
|
2016-02-10 23:53:50 +08:00
|
|
|
* The work may not be allowed to be queued up right now.
|
|
|
|
* Possible reasons:
|
|
|
|
* - Work has already been queued up or is in progress.
|
|
|
|
* - It is too early (too little time from the previous sample).
|
2015-12-09 10:04:42 +08:00
|
|
|
*/
|
2016-02-09 06:41:10 +08:00
|
|
|
if (atomic_inc_return(&policy_dbs->work_count) == 1) {
|
2016-02-10 23:53:50 +08:00
|
|
|
u64 delta_ns;
|
|
|
|
|
2016-02-11 00:07:44 +08:00
|
|
|
delta_ns = time - policy_dbs->last_sample_time;
|
|
|
|
if ((s64)delta_ns >= policy_dbs->sample_delay_ns) {
|
|
|
|
policy_dbs->last_sample_time = time;
|
2016-02-16 05:15:34 +08:00
|
|
|
irq_work_queue(&policy_dbs->irq_work);
|
2016-02-10 23:53:50 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2016-02-09 06:41:10 +08:00
|
|
|
atomic_dec(&policy_dbs->work_count);
|
2015-07-18 14:01:00 +08:00
|
|
|
}
|
2013-02-01 01:28:02 +08:00
|
|
|
|
2016-02-07 23:24:26 +08:00
|
|
|
static struct policy_dbs_info *alloc_policy_dbs_info(struct cpufreq_policy *policy,
|
|
|
|
struct dbs_governor *gov)
|
2015-07-18 14:00:59 +08:00
|
|
|
{
|
2016-02-11 00:07:44 +08:00
|
|
|
struct policy_dbs_info *policy_dbs;
|
2015-07-18 14:00:59 +08:00
|
|
|
int j;
|
|
|
|
|
|
|
|
/* Allocate memory for the common information for policy->cpus */
|
2016-02-11 00:07:44 +08:00
|
|
|
policy_dbs = kzalloc(sizeof(*policy_dbs), GFP_KERNEL);
|
|
|
|
if (!policy_dbs)
|
2016-02-07 23:24:26 +08:00
|
|
|
return NULL;
|
2015-07-18 14:00:59 +08:00
|
|
|
|
2016-02-11 20:01:14 +08:00
|
|
|
policy_dbs->policy = policy;
|
2016-02-11 00:07:44 +08:00
|
|
|
mutex_init(&policy_dbs->timer_mutex);
|
2016-02-09 06:41:10 +08:00
|
|
|
atomic_set(&policy_dbs->work_count, 0);
|
2016-02-11 00:07:44 +08:00
|
|
|
init_irq_work(&policy_dbs->irq_work, dbs_irq_work);
|
|
|
|
INIT_WORK(&policy_dbs->work, dbs_work_handler);
|
2016-02-07 23:25:02 +08:00
|
|
|
|
|
|
|
/* Set policy_dbs for all CPUs, online+offline */
|
|
|
|
for_each_cpu(j, policy->related_cpus) {
|
|
|
|
struct cpu_dbs_info *j_cdbs = gov->get_cpu_cdbs(j);
|
|
|
|
|
|
|
|
j_cdbs->policy_dbs = policy_dbs;
|
|
|
|
j_cdbs->update_util.func = dbs_update_util_handler;
|
|
|
|
}
|
2016-02-07 23:24:26 +08:00
|
|
|
return policy_dbs;
|
2015-07-18 14:00:59 +08:00
|
|
|
}
|
|
|
|
|
2016-02-11 00:07:44 +08:00
|
|
|
static void free_policy_dbs_info(struct cpufreq_policy *policy,
|
2016-02-07 23:05:07 +08:00
|
|
|
struct dbs_governor *gov)
|
2015-07-18 14:00:59 +08:00
|
|
|
{
|
2016-02-07 23:05:07 +08:00
|
|
|
struct cpu_dbs_info *cdbs = gov->get_cpu_cdbs(policy->cpu);
|
2016-02-11 00:07:44 +08:00
|
|
|
struct policy_dbs_info *policy_dbs = cdbs->policy_dbs;
|
2015-07-18 14:00:59 +08:00
|
|
|
int j;
|
|
|
|
|
2016-02-11 00:07:44 +08:00
|
|
|
mutex_destroy(&policy_dbs->timer_mutex);
|
2015-12-03 12:07:52 +08:00
|
|
|
|
2016-02-07 23:25:02 +08:00
|
|
|
for_each_cpu(j, policy->related_cpus) {
|
|
|
|
struct cpu_dbs_info *j_cdbs = gov->get_cpu_cdbs(j);
|
2015-07-18 14:00:59 +08:00
|
|
|
|
2016-02-07 23:25:02 +08:00
|
|
|
j_cdbs->policy_dbs = NULL;
|
|
|
|
j_cdbs->update_util.func = NULL;
|
|
|
|
}
|
2016-02-11 00:07:44 +08:00
|
|
|
kfree(policy_dbs);
|
2015-07-18 14:00:59 +08:00
|
|
|
}
|
|
|
|
|
2016-02-07 23:07:51 +08:00
|
|
|
static int cpufreq_governor_init(struct cpufreq_policy *policy)
|
2012-10-26 06:47:42 +08:00
|
|
|
{
|
2016-02-07 23:09:51 +08:00
|
|
|
struct dbs_governor *gov = dbs_governor_of(policy);
|
2016-02-07 23:05:07 +08:00
|
|
|
struct dbs_data *dbs_data = gov->gdbs_data;
|
2016-02-07 23:24:26 +08:00
|
|
|
struct policy_dbs_info *policy_dbs;
|
2015-06-04 19:13:27 +08:00
|
|
|
unsigned int latency;
|
|
|
|
int ret;
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2015-07-18 14:01:01 +08:00
|
|
|
/* State should be equivalent to EXIT */
|
|
|
|
if (policy->governor_data)
|
|
|
|
return -EBUSY;
|
|
|
|
|
2016-02-07 23:24:26 +08:00
|
|
|
policy_dbs = alloc_policy_dbs_info(policy, gov);
|
|
|
|
if (!policy_dbs)
|
|
|
|
return -ENOMEM;
|
2015-07-18 14:00:59 +08:00
|
|
|
|
2016-02-07 23:24:26 +08:00
|
|
|
if (dbs_data) {
|
|
|
|
if (WARN_ON(have_governor_per_policy())) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto free_policy_dbs_info;
|
|
|
|
}
|
|
|
|
policy_dbs->dbs_data = dbs_data;
|
|
|
|
policy->governor_data = policy_dbs;
|
2016-02-10 13:30:25 +08:00
|
|
|
|
|
|
|
mutex_lock(&dbs_data->mutex);
|
|
|
|
dbs_data->usage_count++;
|
|
|
|
list_add(&policy_dbs->list, &dbs_data->policy_dbs_list);
|
|
|
|
mutex_unlock(&dbs_data->mutex);
|
|
|
|
|
2015-06-04 19:13:27 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2013-03-27 23:58:58 +08:00
|
|
|
|
2015-06-04 19:13:27 +08:00
|
|
|
dbs_data = kzalloc(sizeof(*dbs_data), GFP_KERNEL);
|
2016-02-07 23:24:26 +08:00
|
|
|
if (!dbs_data) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto free_policy_dbs_info;
|
|
|
|
}
|
2015-07-18 14:00:59 +08:00
|
|
|
|
2016-02-10 13:30:25 +08:00
|
|
|
INIT_LIST_HEAD(&dbs_data->policy_dbs_list);
|
cpufreq: governor: New sysfs show/store callbacks for governor tunables
The ondemand and conservative governors use the global-attr or freq-attr
structures to represent sysfs attributes corresponding to their tunables
(which of them is actually used depends on whether or not different
policy objects can use the same governor with different tunables at the
same time and, consequently, on where those attributes are located in
sysfs).
Unfortunately, in the freq-attr case, the standard cpufreq show/store
sysfs attribute callbacks are applied to the governor tunable attributes
and they always acquire the policy->rwsem lock before carrying out the
operation. That may lead to an ABBA deadlock if governor tunable
attributes are removed under policy->rwsem while one of them is being
accessed concurrently (if sysfs attributes removal wins the race, it
will wait for the access to complete with policy->rwsem held while the
attribute callback will block on policy->rwsem indefinitely).
We attempted to address this issue by dropping policy->rwsem around
governor tunable attributes removal (that is, around invocations of the
->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT)
in cpufreq_set_policy(), but that opened up race conditions that had not
been possible with policy->rwsem held all the time. Therefore
policy->rwsem cannot be dropped in cpufreq_set_policy() at any point,
but the deadlock situation described above must be avoided too.
To that end, use the observation that in principle governor tunables may
be represented by the same data type regardless of whether the governor
is system-wide or per-policy and introduce a new structure, struct
governor_attr, for representing them and new corresponding macros for
creating show/store sysfs callbacks for them. Also make their parent
kobject use a new kobject type whose default show/store callbacks are
not related to the standard core cpufreq ones in any way (and they don't
acquire policy->rwsem in particular).
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Juri Lelli <juri.lelli@arm.com>
Tested-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
[ rjw: Subject & changelog + rebase ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-09 11:31:33 +08:00
|
|
|
mutex_init(&dbs_data->mutex);
|
2013-03-27 23:58:58 +08:00
|
|
|
|
2016-02-07 23:05:07 +08:00
|
|
|
ret = gov->init(dbs_data, !policy->governor->initialized);
|
2015-06-04 19:13:27 +08:00
|
|
|
if (ret)
|
2016-02-11 00:07:44 +08:00
|
|
|
goto free_policy_dbs_info;
|
2013-03-27 23:58:58 +08:00
|
|
|
|
2015-06-04 19:13:27 +08:00
|
|
|
/* policy latency is in ns. Convert it to us first */
|
|
|
|
latency = policy->cpuinfo.transition_latency / 1000;
|
|
|
|
if (latency == 0)
|
|
|
|
latency = 1;
|
2013-03-27 23:58:58 +08:00
|
|
|
|
2015-06-04 19:13:27 +08:00
|
|
|
/* Bring kernel and HW constraints together */
|
|
|
|
dbs_data->min_sampling_rate = max(dbs_data->min_sampling_rate,
|
|
|
|
MIN_LATENCY_MULTIPLIER * latency);
|
2016-02-09 11:31:32 +08:00
|
|
|
dbs_data->sampling_rate = max(dbs_data->min_sampling_rate,
|
|
|
|
LATENCY_MULTIPLIER * latency);
|
2013-05-17 18:39:09 +08:00
|
|
|
|
2015-10-16 00:05:22 +08:00
|
|
|
if (!have_governor_per_policy())
|
2016-02-07 23:05:07 +08:00
|
|
|
gov->gdbs_data = dbs_data;
|
2013-03-27 23:58:58 +08:00
|
|
|
|
2016-02-07 23:24:26 +08:00
|
|
|
policy->governor_data = policy_dbs;
|
2016-01-26 01:03:46 +08:00
|
|
|
|
2016-02-10 13:30:25 +08:00
|
|
|
policy_dbs->dbs_data = dbs_data;
|
|
|
|
dbs_data->usage_count = 1;
|
|
|
|
list_add(&policy_dbs->list, &dbs_data->policy_dbs_list);
|
|
|
|
|
cpufreq: governor: New sysfs show/store callbacks for governor tunables
The ondemand and conservative governors use the global-attr or freq-attr
structures to represent sysfs attributes corresponding to their tunables
(which of them is actually used depends on whether or not different
policy objects can use the same governor with different tunables at the
same time and, consequently, on where those attributes are located in
sysfs).
Unfortunately, in the freq-attr case, the standard cpufreq show/store
sysfs attribute callbacks are applied to the governor tunable attributes
and they always acquire the policy->rwsem lock before carrying out the
operation. That may lead to an ABBA deadlock if governor tunable
attributes are removed under policy->rwsem while one of them is being
accessed concurrently (if sysfs attributes removal wins the race, it
will wait for the access to complete with policy->rwsem held while the
attribute callback will block on policy->rwsem indefinitely).
We attempted to address this issue by dropping policy->rwsem around
governor tunable attributes removal (that is, around invocations of the
->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT)
in cpufreq_set_policy(), but that opened up race conditions that had not
been possible with policy->rwsem held all the time. Therefore
policy->rwsem cannot be dropped in cpufreq_set_policy() at any point,
but the deadlock situation described above must be avoided too.
To that end, use the observation that in principle governor tunables may
be represented by the same data type regardless of whether the governor
is system-wide or per-policy and introduce a new structure, struct
governor_attr, for representing them and new corresponding macros for
creating show/store sysfs callbacks for them. Also make their parent
kobject use a new kobject type whose default show/store callbacks are
not related to the standard core cpufreq ones in any way (and they don't
acquire policy->rwsem in particular).
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Juri Lelli <juri.lelli@arm.com>
Tested-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
[ rjw: Subject & changelog + rebase ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-09 11:31:33 +08:00
|
|
|
gov->kobj_type.sysfs_ops = &governor_sysfs_ops;
|
|
|
|
ret = kobject_init_and_add(&dbs_data->kobj, &gov->kobj_type,
|
|
|
|
get_governor_parent_kobj(policy),
|
|
|
|
"%s", gov->gov.name);
|
2016-02-09 06:57:22 +08:00
|
|
|
if (!ret)
|
|
|
|
return 0;
|
2013-03-27 23:58:58 +08:00
|
|
|
|
2016-02-09 06:57:22 +08:00
|
|
|
/* Failure, so roll back. */
|
cpufreq: governor: New sysfs show/store callbacks for governor tunables
The ondemand and conservative governors use the global-attr or freq-attr
structures to represent sysfs attributes corresponding to their tunables
(which of them is actually used depends on whether or not different
policy objects can use the same governor with different tunables at the
same time and, consequently, on where those attributes are located in
sysfs).
Unfortunately, in the freq-attr case, the standard cpufreq show/store
sysfs attribute callbacks are applied to the governor tunable attributes
and they always acquire the policy->rwsem lock before carrying out the
operation. That may lead to an ABBA deadlock if governor tunable
attributes are removed under policy->rwsem while one of them is being
accessed concurrently (if sysfs attributes removal wins the race, it
will wait for the access to complete with policy->rwsem held while the
attribute callback will block on policy->rwsem indefinitely).
We attempted to address this issue by dropping policy->rwsem around
governor tunable attributes removal (that is, around invocations of the
->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT)
in cpufreq_set_policy(), but that opened up race conditions that had not
been possible with policy->rwsem held all the time. Therefore
policy->rwsem cannot be dropped in cpufreq_set_policy() at any point,
but the deadlock situation described above must be avoided too.
To that end, use the observation that in principle governor tunables may
be represented by the same data type regardless of whether the governor
is system-wide or per-policy and introduce a new structure, struct
governor_attr, for representing them and new corresponding macros for
creating show/store sysfs callbacks for them. Also make their parent
kobject use a new kobject type whose default show/store callbacks are
not related to the standard core cpufreq ones in any way (and they don't
acquire policy->rwsem in particular).
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Juri Lelli <juri.lelli@arm.com>
Tested-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
[ rjw: Subject & changelog + rebase ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-09 11:31:33 +08:00
|
|
|
pr_err("cpufreq: Governor initialization failed (dbs_data kobject init error %d)\n", ret);
|
2013-03-27 23:58:58 +08:00
|
|
|
|
2016-01-26 01:03:46 +08:00
|
|
|
policy->governor_data = NULL;
|
|
|
|
|
2015-10-16 00:05:22 +08:00
|
|
|
if (!have_governor_per_policy())
|
2016-02-07 23:05:07 +08:00
|
|
|
gov->gdbs_data = NULL;
|
|
|
|
gov->exit(dbs_data, !policy->governor->initialized);
|
2016-02-07 23:24:26 +08:00
|
|
|
kfree(dbs_data);
|
|
|
|
|
2016-02-11 00:07:44 +08:00
|
|
|
free_policy_dbs_info:
|
|
|
|
free_policy_dbs_info(policy, gov);
|
2015-06-04 19:13:27 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2013-03-27 23:58:58 +08:00
|
|
|
|
2016-02-05 10:15:24 +08:00
|
|
|
static int cpufreq_governor_exit(struct cpufreq_policy *policy)
|
2015-06-04 19:13:27 +08:00
|
|
|
{
|
2016-02-07 23:09:51 +08:00
|
|
|
struct dbs_governor *gov = dbs_governor_of(policy);
|
2016-02-07 23:24:26 +08:00
|
|
|
struct policy_dbs_info *policy_dbs = policy->governor_data;
|
|
|
|
struct dbs_data *dbs_data = policy_dbs->dbs_data;
|
2016-02-10 13:30:25 +08:00
|
|
|
int count;
|
2015-07-18 14:01:01 +08:00
|
|
|
|
2016-02-10 13:30:25 +08:00
|
|
|
mutex_lock(&dbs_data->mutex);
|
|
|
|
list_del(&policy_dbs->list);
|
|
|
|
count = --dbs_data->usage_count;
|
|
|
|
mutex_unlock(&dbs_data->mutex);
|
|
|
|
|
|
|
|
if (!count) {
|
cpufreq: governor: New sysfs show/store callbacks for governor tunables
The ondemand and conservative governors use the global-attr or freq-attr
structures to represent sysfs attributes corresponding to their tunables
(which of them is actually used depends on whether or not different
policy objects can use the same governor with different tunables at the
same time and, consequently, on where those attributes are located in
sysfs).
Unfortunately, in the freq-attr case, the standard cpufreq show/store
sysfs attribute callbacks are applied to the governor tunable attributes
and they always acquire the policy->rwsem lock before carrying out the
operation. That may lead to an ABBA deadlock if governor tunable
attributes are removed under policy->rwsem while one of them is being
accessed concurrently (if sysfs attributes removal wins the race, it
will wait for the access to complete with policy->rwsem held while the
attribute callback will block on policy->rwsem indefinitely).
We attempted to address this issue by dropping policy->rwsem around
governor tunable attributes removal (that is, around invocations of the
->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT)
in cpufreq_set_policy(), but that opened up race conditions that had not
been possible with policy->rwsem held all the time. Therefore
policy->rwsem cannot be dropped in cpufreq_set_policy() at any point,
but the deadlock situation described above must be avoided too.
To that end, use the observation that in principle governor tunables may
be represented by the same data type regardless of whether the governor
is system-wide or per-policy and introduce a new structure, struct
governor_attr, for representing them and new corresponding macros for
creating show/store sysfs callbacks for them. Also make their parent
kobject use a new kobject type whose default show/store callbacks are
not related to the standard core cpufreq ones in any way (and they don't
acquire policy->rwsem in particular).
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Juri Lelli <juri.lelli@arm.com>
Tested-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
[ rjw: Subject & changelog + rebase ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-09 11:31:33 +08:00
|
|
|
kobject_put(&dbs_data->kobj);
|
2013-05-17 18:39:09 +08:00
|
|
|
|
2016-01-26 01:03:46 +08:00
|
|
|
policy->governor_data = NULL;
|
|
|
|
|
2015-10-16 00:05:22 +08:00
|
|
|
if (!have_governor_per_policy())
|
2016-02-07 23:05:07 +08:00
|
|
|
gov->gdbs_data = NULL;
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2016-02-07 23:05:07 +08:00
|
|
|
gov->exit(dbs_data, policy->governor->initialized == 1);
|
cpufreq: governor: New sysfs show/store callbacks for governor tunables
The ondemand and conservative governors use the global-attr or freq-attr
structures to represent sysfs attributes corresponding to their tunables
(which of them is actually used depends on whether or not different
policy objects can use the same governor with different tunables at the
same time and, consequently, on where those attributes are located in
sysfs).
Unfortunately, in the freq-attr case, the standard cpufreq show/store
sysfs attribute callbacks are applied to the governor tunable attributes
and they always acquire the policy->rwsem lock before carrying out the
operation. That may lead to an ABBA deadlock if governor tunable
attributes are removed under policy->rwsem while one of them is being
accessed concurrently (if sysfs attributes removal wins the race, it
will wait for the access to complete with policy->rwsem held while the
attribute callback will block on policy->rwsem indefinitely).
We attempted to address this issue by dropping policy->rwsem around
governor tunable attributes removal (that is, around invocations of the
->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT)
in cpufreq_set_policy(), but that opened up race conditions that had not
been possible with policy->rwsem held all the time. Therefore
policy->rwsem cannot be dropped in cpufreq_set_policy() at any point,
but the deadlock situation described above must be avoided too.
To that end, use the observation that in principle governor tunables may
be represented by the same data type regardless of whether the governor
is system-wide or per-policy and introduce a new structure, struct
governor_attr, for representing them and new corresponding macros for
creating show/store sysfs callbacks for them. Also make their parent
kobject use a new kobject type whose default show/store callbacks are
not related to the standard core cpufreq ones in any way (and they don't
acquire policy->rwsem in particular).
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Juri Lelli <juri.lelli@arm.com>
Tested-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
[ rjw: Subject & changelog + rebase ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-09 11:31:33 +08:00
|
|
|
mutex_destroy(&dbs_data->mutex);
|
2015-06-04 19:13:27 +08:00
|
|
|
kfree(dbs_data);
|
2016-01-26 01:03:46 +08:00
|
|
|
} else {
|
|
|
|
policy->governor_data = NULL;
|
2013-03-27 23:58:58 +08:00
|
|
|
}
|
2015-07-18 14:00:59 +08:00
|
|
|
|
2016-02-11 00:07:44 +08:00
|
|
|
free_policy_dbs_info(policy, gov);
|
2015-07-18 14:01:01 +08:00
|
|
|
return 0;
|
2015-06-04 19:13:27 +08:00
|
|
|
}
|
2013-03-27 23:58:58 +08:00
|
|
|
|
2016-02-05 10:15:24 +08:00
|
|
|
static int cpufreq_governor_start(struct cpufreq_policy *policy)
|
2015-06-04 19:13:27 +08:00
|
|
|
{
|
2016-02-07 23:09:51 +08:00
|
|
|
struct dbs_governor *gov = dbs_governor_of(policy);
|
2016-02-07 23:24:26 +08:00
|
|
|
struct policy_dbs_info *policy_dbs = policy->governor_data;
|
|
|
|
struct dbs_data *dbs_data = policy_dbs->dbs_data;
|
2015-06-04 19:13:27 +08:00
|
|
|
unsigned int sampling_rate, ignore_nice, j, cpu = policy->cpu;
|
|
|
|
int io_busy = 0;
|
|
|
|
|
|
|
|
if (!policy->cur)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2016-02-09 11:31:32 +08:00
|
|
|
sampling_rate = dbs_data->sampling_rate;
|
|
|
|
ignore_nice = dbs_data->ignore_nice_load;
|
2013-03-27 23:58:58 +08:00
|
|
|
|
2016-02-09 11:31:32 +08:00
|
|
|
if (gov->governor == GOV_ONDEMAND) {
|
2015-06-04 19:13:27 +08:00
|
|
|
struct od_dbs_tuners *od_tuners = dbs_data->tuners;
|
|
|
|
|
2013-03-01 00:57:32 +08:00
|
|
|
io_busy = od_tuners->io_is_busy;
|
2012-10-26 06:47:42 +08:00
|
|
|
}
|
|
|
|
|
2015-06-04 19:13:27 +08:00
|
|
|
for_each_cpu(j, policy->cpus) {
|
2016-02-07 23:05:07 +08:00
|
|
|
struct cpu_dbs_info *j_cdbs = gov->get_cpu_cdbs(j);
|
2015-06-04 19:13:27 +08:00
|
|
|
unsigned int prev_load;
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2015-06-04 19:13:27 +08:00
|
|
|
j_cdbs->prev_cpu_idle =
|
|
|
|
get_cpu_idle_time(j, &j_cdbs->prev_cpu_wall, io_busy);
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2015-06-04 19:13:27 +08:00
|
|
|
prev_load = (unsigned int)(j_cdbs->prev_cpu_wall -
|
|
|
|
j_cdbs->prev_cpu_idle);
|
|
|
|
j_cdbs->prev_load = 100 * prev_load /
|
|
|
|
(unsigned int)j_cdbs->prev_cpu_wall;
|
cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
Cpufreq governors like the ondemand governor calculate the load on the CPU
periodically by employing deferrable timers. A deferrable timer won't fire
if the CPU is completely idle (and there are no other timers to be run), in
order to avoid unnecessary wakeups and thus save CPU power.
However, the load calculation logic is agnostic to all this, and this can
lead to the problem described below.
Time (ms) CPU 1
100 Task-A running
110 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
110.5 Task-A running
120 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
125 Task-A went to sleep. With nothing else to do, CPU 1
went completely idle.
200 Task-A woke up and started running again.
200.5 Governor's deferred timer (which was originally programmed
to fire at time 130) fires now. It calculates load for the
time period 120 to 200.5, and finds the load is almost zero.
Hence it decreases the CPU frequency to the minimum.
210 Governor's timer fires, finds load as 100% in the last
10ms interval and increases the CPU frequency.
So, after the workload woke up and started running, the frequency was suddenly
dropped to absolute minimum, and after that, there was an unnecessary delay of
10ms (sampling period) to increase the CPU frequency back to a reasonable value.
And this pattern repeats for every wake-up-from-cpu-idle for that workload.
This can be quite undesirable for latency- or response-time sensitive bursty
workloads. So we need to fix the governor's logic to detect such wake-up-from-
cpu-idle scenarios and start the workload at a reasonably high CPU frequency.
One extreme solution would be to fake a load of 100% in such scenarios. But
that might lead to undesirable side-effects such as frequency spikes (which
might also need voltage changes) especially if the previous frequency happened
to be very low.
We just want to avoid the stupidity of dropping down the frequency to a minimum
and then enduring a needless (and long) delay before ramping it up back again.
So, let us simply carry forward the previous load - that is, let us just pretend
that the 'load' for the current time-window is the same as the load for the
previous window. That way, the frequency and voltage will continue to be set
to whatever values they were set at previously. This means that bursty workloads
will get a chance to influence the CPU frequency at which they wake up from
cpu-idle, based on their past execution history. Thus, they might be able to
avoid suffering from slow wakeups and long response-times.
However, we should take care not to over-do this. For example, such a "copy
previous load" logic will benefit cases like this: (where # represents busy
and . represents idle)
##########.........#########.........###########...........##########........
but it will be detrimental in cases like the one shown below, because it will
retain the high frequency (copied from the previous interval) even in a mostly
idle system:
##########.........#.................#.....................#...............
(i.e., the workload finished and the remaining tasks are such that their busy
periods are smaller than the sampling interval, which causes the timer to
always get deferred. So, this will make the copy-previous-load logic copy
the initial high load to subsequent idle periods over and over again, thus
keeping the frequency high unnecessarily).
So, we modify this copy-previous-load logic such that it is used only once
upon every wakeup-from-idle. Thus if we have 2 consecutive idle periods, the
previous load won't get blindly copied over; cpufreq will freshly evaluate the
load in the second idle interval, thus ensuring that the system comes back to
its normal state.
[ The right way to solve this whole problem is to teach the CPU frequency
governors to also track load on a per-task basis, not just a per-CPU basis,
and then use both the data sources intelligently to set the appropriate
frequency on the CPUs. But that involves redesigning the cpufreq subsystem,
so this patch should make the situation bearable until then. ]
Experimental results:
+-------------------+
I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in
between its execution such that its total utilization can be a user-defined
value, say 10% or 20% (higher the utilization specified, lesser the amount of
sleeps injected). This ebizzy was run with a single-thread, tied to CPU 8.
Behavior observed with tracing (sample taken from 40% utilization runs):
------------------------------------------------------------------------
Without patch:
~~~~~~~~~~~~~~
kworker/8:2-12137 416.335742: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.335744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.345741: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.345744: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.345746: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.355738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
<...>-40753 416.402202: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 416.502130: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40753 416.505738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.505739: cpu_frequency: state=2061000 cpu_id=8
kworker/8:2-12137 416.505741: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40753 416.515739: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-12137 416.515742: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-12137 416.515744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
Observation: Ebizzy went idle at 416.402202, and started running again at
416.502130. But cpufreq noticed the long idle period, and dropped the frequency
at 416.505739, only to increase it back again at 416.515742, realizing that the
workload is in-fact CPU bound. Thus ebizzy needlessly ran at the lowest frequency
for almost 13 milliseconds (almost 1 full sample period), and this pattern
repeats on every sleep-wakeup. This could hurt latency-sensitive workloads quite
a lot.
With patch:
~~~~~~~~~~~
kworker/8:2-29802 464.832535: cpu_frequency: state=2061000 cpu_id=8
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 464.962538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.972533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 464.972536: cpu_frequency: state=4123000 cpu_id=8
kworker/8:2-29802 464.972538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 464.982531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
<snip> --------------------------------------------------------------------- <snip>
kworker/8:2-29802 465.022533: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.032531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.032532: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.035797: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
<idle>-0 465.240178: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
<...>-40738 465.242533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
kworker/8:2-29802 465.242535: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy
<...>-40738 465.252531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2
Observation: Ebizzy went idle at 465.035797, and started running again at
465.240178. Since ebizzy was the only real workload running on this CPU,
cpufreq retained the frequency at 4.1Ghz throughout the run of ebizzy, no
matter how many times ebizzy slept and woke-up in-between. Thus, ebizzy
got the 10ms worth of 4.1 Ghz benefit during every sleep-wakeup (as compared
to the run without the patch) and this boost gave a modest improvement in total
throughput, as shown below.
Sleeping-ebizzy records-per-second:
-----------------------------------
Utilization Without patch With patch Difference (Absolute and % values)
10% 274767 277046 + 2279 (+0.829%)
20% 543429 553484 + 10055 (+1.850%)
40% 1090744 1107959 + 17215 (+1.578%)
60% 1634908 1662018 + 27110 (+1.658%)
A rudimentary and somewhat approximately latency-sensitive workload such as
sleeping-ebizzy itself showed a consistent, noticeable performance improvement
with this patch. Hence, workloads that are truly latency-sensitive will benefit
quite a bit from this change. Moreover, this is an overall win-win since this
patch does not hurt power-savings at all (because, this patch does not reduce
the idle time or idle residency; and the high frequency of the CPU when it goes
to cpu-idle does not affect/hurt the power-savings of deep idle states).
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-08 04:41:43 +08:00
|
|
|
|
2015-06-04 19:13:27 +08:00
|
|
|
if (ignore_nice)
|
|
|
|
j_cdbs->prev_cpu_nice = kcpustat_cpu(j).cpustat[CPUTIME_NICE];
|
|
|
|
}
|
2012-12-27 22:55:38 +08:00
|
|
|
|
2016-02-07 23:05:07 +08:00
|
|
|
if (gov->governor == GOV_CONSERVATIVE) {
|
2015-06-04 19:13:27 +08:00
|
|
|
struct cs_cpu_dbs_info_s *cs_dbs_info =
|
2016-02-07 23:05:07 +08:00
|
|
|
gov->get_cpu_dbs_info_s(cpu);
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2015-06-04 19:13:27 +08:00
|
|
|
cs_dbs_info->down_skip = 0;
|
|
|
|
cs_dbs_info->requested_freq = policy->cur;
|
|
|
|
} else {
|
2016-02-07 23:05:07 +08:00
|
|
|
struct od_ops *od_ops = gov->gov_ops;
|
|
|
|
struct od_cpu_dbs_info_s *od_dbs_info = gov->get_cpu_dbs_info_s(cpu);
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2015-06-04 19:13:27 +08:00
|
|
|
od_dbs_info->rate_mult = 1;
|
|
|
|
od_dbs_info->sample_type = OD_NORMAL_SAMPLE;
|
|
|
|
od_ops->powersave_bias_init_cpu(cpu);
|
|
|
|
}
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2016-02-11 00:07:44 +08:00
|
|
|
gov_set_update_util(policy_dbs, sampling_rate);
|
2015-06-04 19:13:27 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-02-05 10:15:24 +08:00
|
|
|
static int cpufreq_governor_stop(struct cpufreq_policy *policy)
|
2015-06-04 19:13:27 +08:00
|
|
|
{
|
2016-02-11 20:01:14 +08:00
|
|
|
gov_cancel_work(policy);
|
2015-10-29 10:38:38 +08:00
|
|
|
|
2015-07-18 14:01:01 +08:00
|
|
|
return 0;
|
2015-06-04 19:13:27 +08:00
|
|
|
}
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2016-02-05 10:15:24 +08:00
|
|
|
static int cpufreq_governor_limits(struct cpufreq_policy *policy)
|
2015-06-04 19:13:27 +08:00
|
|
|
{
|
2016-02-07 23:24:26 +08:00
|
|
|
struct policy_dbs_info *policy_dbs = policy->governor_data;
|
2013-02-01 01:28:01 +08:00
|
|
|
|
2016-02-07 23:23:49 +08:00
|
|
|
mutex_lock(&policy_dbs->timer_mutex);
|
|
|
|
if (policy->max < policy->cur)
|
|
|
|
__cpufreq_driver_target(policy, policy->max, CPUFREQ_RELATION_H);
|
|
|
|
else if (policy->min > policy->cur)
|
|
|
|
__cpufreq_driver_target(policy, policy->min, CPUFREQ_RELATION_L);
|
2016-02-06 20:50:24 +08:00
|
|
|
dbs_check_cpu(policy);
|
2016-02-07 23:23:49 +08:00
|
|
|
mutex_unlock(&policy_dbs->timer_mutex);
|
2015-07-18 14:01:01 +08:00
|
|
|
|
|
|
|
return 0;
|
2015-06-04 19:13:27 +08:00
|
|
|
}
|
2012-10-26 06:47:42 +08:00
|
|
|
|
2016-02-07 23:07:51 +08:00
|
|
|
int cpufreq_governor_dbs(struct cpufreq_policy *policy, unsigned int event)
|
2015-06-04 19:13:27 +08:00
|
|
|
{
|
2016-02-05 10:15:24 +08:00
|
|
|
int ret = -EINVAL;
|
2015-06-04 19:13:27 +08:00
|
|
|
|
cpufreq: governor: Serialize governor callbacks
There are several races reported in cpufreq core around governors (only
ondemand and conservative) by different people.
There are at least two race scenarios present in governor code:
(a) Concurrent access/updates of governor internal structures.
It is possible that fields such as 'dbs_data->usage_count', etc. are
accessed simultaneously for different policies using same governor
structure (i.e. CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag unset). And
because of this we can dereference bad pointers.
For example consider a system with two CPUs with separate 'struct
cpufreq_policy' instances. CPU0 governor: ondemand and CPU1: powersave.
CPU0 switching to powersave and CPU1 to ondemand:
CPU0 CPU1
store* store*
cpufreq_governor_exit() cpufreq_governor_init()
dbs_data = cdata->gdbs_data;
if (!--dbs_data->usage_count)
kfree(dbs_data);
dbs_data->usage_count++;
*Bad pointer dereference*
There are other races possible between EXIT and START/STOP/LIMIT as
well. Its really complicated.
(b) Switching governor state in bad sequence:
For example trying to switch a governor to START state, when the
governor is in EXIT state. There are some checks present in
__cpufreq_governor() but they aren't sufficient as they compare events
against 'policy->governor_enabled', where as we need to take governor's
state into account, which can be used by multiple policies.
These two issues need to be solved separately and the responsibility
should be properly divided between cpufreq and governor core.
The first problem is more about the governor core, as it needs to
protect its structures properly. And the second problem should be fixed
in cpufreq core instead of governor, as its all about sequence of
events.
This patch is trying to solve only the first problem.
There are two types of data we need to protect,
- 'struct common_dbs_data': No matter what, there is going to be a
single copy of this per governor.
- 'struct dbs_data': With CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag set, we
will have per-policy copy of this data, otherwise a single copy.
Because of such complexities, the mutex present in 'struct dbs_data' is
insufficient to solve our problem. For example we need to protect
fetching of 'dbs_data' from different structures at the beginning of
cpufreq_governor_dbs(), to make sure it isn't currently being updated.
This can be fixed if we can guarantee serialization of event parsing
code for an individual governor. This is best solved with a mutex per
governor, and the placeholder for that is 'struct common_dbs_data'.
And so this patch moves the mutex from 'struct dbs_data' to 'struct
common_dbs_data' and takes it at the beginning and drops it at the end
of cpufreq_governor_dbs().
Tested with and without following configuration options:
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-03 18:27:13 +08:00
|
|
|
/* Lock governor to block concurrent initialization of governor */
|
2016-02-07 23:01:31 +08:00
|
|
|
mutex_lock(&dbs_data_mutex);
|
cpufreq: governor: Serialize governor callbacks
There are several races reported in cpufreq core around governors (only
ondemand and conservative) by different people.
There are at least two race scenarios present in governor code:
(a) Concurrent access/updates of governor internal structures.
It is possible that fields such as 'dbs_data->usage_count', etc. are
accessed simultaneously for different policies using same governor
structure (i.e. CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag unset). And
because of this we can dereference bad pointers.
For example consider a system with two CPUs with separate 'struct
cpufreq_policy' instances. CPU0 governor: ondemand and CPU1: powersave.
CPU0 switching to powersave and CPU1 to ondemand:
CPU0 CPU1
store* store*
cpufreq_governor_exit() cpufreq_governor_init()
dbs_data = cdata->gdbs_data;
if (!--dbs_data->usage_count)
kfree(dbs_data);
dbs_data->usage_count++;
*Bad pointer dereference*
There are other races possible between EXIT and START/STOP/LIMIT as
well. Its really complicated.
(b) Switching governor state in bad sequence:
For example trying to switch a governor to START state, when the
governor is in EXIT state. There are some checks present in
__cpufreq_governor() but they aren't sufficient as they compare events
against 'policy->governor_enabled', where as we need to take governor's
state into account, which can be used by multiple policies.
These two issues need to be solved separately and the responsibility
should be properly divided between cpufreq and governor core.
The first problem is more about the governor core, as it needs to
protect its structures properly. And the second problem should be fixed
in cpufreq core instead of governor, as its all about sequence of
events.
This patch is trying to solve only the first problem.
There are two types of data we need to protect,
- 'struct common_dbs_data': No matter what, there is going to be a
single copy of this per governor.
- 'struct dbs_data': With CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag set, we
will have per-policy copy of this data, otherwise a single copy.
Because of such complexities, the mutex present in 'struct dbs_data' is
insufficient to solve our problem. For example we need to protect
fetching of 'dbs_data' from different structures at the beginning of
cpufreq_governor_dbs(), to make sure it isn't currently being updated.
This can be fixed if we can guarantee serialization of event parsing
code for an individual governor. This is best solved with a mutex per
governor, and the placeholder for that is 'struct common_dbs_data'.
And so this patch moves the mutex from 'struct dbs_data' to 'struct
common_dbs_data' and takes it at the beginning and drops it at the end
of cpufreq_governor_dbs().
Tested with and without following configuration options:
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-03 18:27:13 +08:00
|
|
|
|
2016-02-05 10:15:24 +08:00
|
|
|
if (event == CPUFREQ_GOV_POLICY_INIT) {
|
2016-02-07 23:07:51 +08:00
|
|
|
ret = cpufreq_governor_init(policy);
|
2016-02-05 10:15:24 +08:00
|
|
|
} else if (policy->governor_data) {
|
|
|
|
switch (event) {
|
|
|
|
case CPUFREQ_GOV_POLICY_EXIT:
|
|
|
|
ret = cpufreq_governor_exit(policy);
|
|
|
|
break;
|
|
|
|
case CPUFREQ_GOV_START:
|
|
|
|
ret = cpufreq_governor_start(policy);
|
|
|
|
break;
|
|
|
|
case CPUFREQ_GOV_STOP:
|
|
|
|
ret = cpufreq_governor_stop(policy);
|
|
|
|
break;
|
|
|
|
case CPUFREQ_GOV_LIMITS:
|
|
|
|
ret = cpufreq_governor_limits(policy);
|
|
|
|
break;
|
|
|
|
}
|
2012-10-26 06:47:42 +08:00
|
|
|
}
|
2015-06-04 19:13:27 +08:00
|
|
|
|
2016-02-07 23:01:31 +08:00
|
|
|
mutex_unlock(&dbs_data_mutex);
|
2015-06-04 19:13:27 +08:00
|
|
|
return ret;
|
2012-10-26 06:47:42 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(cpufreq_governor_dbs);
|