Re: [PATCH linux-next] cpufreq: governors: Calculate iowait time onlywhen necessary
From: Viresh Kumar
Date: Thu Feb 28 2013 - 01:58:20 EST
On Wed, Feb 27, 2013 at 11:14 PM, Stratos Karafotis
<stratosk@xxxxxxxxxxxx> wrote:
> Currently we always calculate the CPU iowait time and add it to idle time.
> If we are in ondemand and we use io_is_busy, we re-calculate iowait time
> and we subtract it from idle time.
>
> With this patch iowait time is calculated only when necessary avoiding
> the double call to get_cpu_iowait_time_us. We use a parameter in
> function get_cpu_idle_time to distinguish when the iowait time will be
> added to idle time or not, without the need of keeping the prev_io_wait.
>
> Signed-off-by: Stratos Karafotis <stratosk@xxxxxxxxxxxx>
> ---
> drivers/cpufreq/cpufreq_conservative.c | 2 +-
> drivers/cpufreq/cpufreq_governor.c | 46 +++++++++++++---------------------
> drivers/cpufreq/cpufreq_governor.h | 3 +--
> drivers/cpufreq/cpufreq_ondemand.c | 11 +++++++-
> 4 files changed, 29 insertions(+), 33 deletions(-)
I have really spent some 10-15 minutes reviewing this patch as initially it
looked to me like something is missing here and calculations are going wrong.
But it was fine :)
> diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
> index f3eb26c..46be2c4 100644
> --- a/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/drivers/cpufreq/cpufreq_ondemand.c
> @@ -339,11 +339,20 @@ static ssize_t store_io_is_busy(struct kobject *a, struct attribute *b,
> {
> + /* we need to re-evaluate prev_cpu_idle */
> + for_each_online_cpu(j) {
> + struct od_cpu_dbs_info_s *dbs_info;
> + dbs_info = &per_cpu(od_cpu_dbs_info, j);
Probably squash above two lines and give a blank line after it.
> + dbs_info->cdbs.prev_cpu_idle = get_cpu_idle_time(j,
> + &dbs_info->cdbs.prev_cpu_wall, od_tuners.io_is_busy);
> + }
> return count;
> }
And after that add my:
Acked-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/