linux-kernel - Re: [PATCH 1/2] sched: Factor out nr_iowait and nr_iowait

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 Oct 2018 09:46:30 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PM <linux-pm@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] sched: Factor out nr_iowait and nr_iowait_cpu

On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano <daniel.lezcano@...aro.org> wrote:
>
> The function nr_iowait_cpu() can be used directly by nr_iowait() instead
> of duplicating code.
>
> Call nr_iowait_cpu() from nr_iowait()
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>

Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>

> ---
>  kernel/sched/core.c | 40 +++++++++++++++++++---------------------
>  1 file changed, 19 insertions(+), 21 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 625bc98..b88a145 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2873,6 +2873,24 @@ unsigned long long nr_context_switches(void)
>
>         return sum;
>  }
> +/*
> + * Consumers of these two interfaces, like for example the cpufreq menu
> + * governor are using nonsensical data. Boosting frequency for a CPU that has
> + * IO-wait which might not even end up running the task when it does become
> + * runnable.
> + */
> +
> +unsigned long nr_iowait_cpu(int cpu)
> +{
> +       return atomic_read(&cpu_rq(cpu)->nr_iowait);
> +}
> +
> +void get_iowait_load(unsigned long *nr_waiters, unsigned long *load)
> +{
> +       struct rq *rq = this_rq();
> +       *nr_waiters = atomic_read(&rq->nr_iowait);
> +       *load = rq->load.weight;
> +}
>
>  /*
>   * IO-wait accounting, and how its mostly bollocks (on SMP).
> @@ -2909,31 +2927,11 @@ unsigned long nr_iowait(void)
>         unsigned long i, sum = 0;
>
>         for_each_possible_cpu(i)
> -               sum += atomic_read(&cpu_rq(i)->nr_iowait);
> +               sum += nr_iowait_cpu(i);
>
>         return sum;
>  }
>
> -/*
> - * Consumers of these two interfaces, like for example the cpufreq menu
> - * governor are using nonsensical data. Boosting frequency for a CPU that has
> - * IO-wait which might not even end up running the task when it does become
> - * runnable.
> - */
> -
> -unsigned long nr_iowait_cpu(int cpu)
> -{
> -       struct rq *this = cpu_rq(cpu);
> -       return atomic_read(&this->nr_iowait);
> -}
> -
> -void get_iowait_load(unsigned long *nr_waiters, unsigned long *load)
> -{
> -       struct rq *rq = this_rq();
> -       *nr_waiters = atomic_read(&rq->nr_iowait);
> -       *load = rq->load.weight;
> -}
> -
>  #ifdef CONFIG_SMP
>
>  /*
> --
> 2.7.4
>