linux-kernel - Re: [PATCH v2] cpufreq: schedutil: rate limits for SCHED

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]

Message-ID: <CAJZ5v0g5SS7A6xNQo=GNaMudRgFC8BL9wP1C4Nh8T-+NygYS+A@mail.gmail.com>
Date:   Wed, 28 Feb 2018 12:22:46 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Claudio Scordino <claudio@...dence.eu.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Ingo Molnar <mingo@...hat.com>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Todd Kjos <tkjos@...roid.com>,
        Joel Fernandes <joelaf@...gle.com>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] cpufreq: schedutil: rate limits for SCHED_DEADLINE

On Wed, Feb 28, 2018 at 12:06 PM, Claudio Scordino
<claudio@...dence.eu.com> wrote:
> When the SCHED_DEADLINE scheduling class increases the CPU utilization,
> we should not wait for the rate limit, otherwise we may miss some
> deadline.
>
> Tests using rt-app on Exynos5422 with up to 10 SCHED_DEADLINE tasks have
> shown reductions of even 10% of deadline misses with a negligible
> increase of energy consumption (measured through Baylibre Cape).
>
> Signed-off-by: Claudio Scordino <claudio@...dence.eu.com>
> CC: Ingo Molnar <mingo@...hat.com>
> CC: Patrick Bellasi <patrick.bellasi@....com>
> CC: Dietmar Eggemann <dietmar.eggemann@....com>
> CC: Morten Rasmussen <morten.rasmussen@....com>
> CC: Juri Lelli <juri.lelli@...hat.com>
> CC: Viresh Kumar <viresh.kumar@...aro.org>
> CC: Vincent Guittot <vincent.guittot@...aro.org>
> CC: Todd Kjos <tkjos@...roid.com>
> CC: Joel Fernandes <joelaf@...gle.com>
> CC: linux-pm@...r.kernel.org
> CC: linux-kernel@...r.kernel.org
> ---
> Changes from v1:
>  - Logic moved from sugov_should_update_freq() to
>    sugov_update_single()/_shared() to not duplicate data structures
>  - Rate limit not ignored in case of "fast switch"

I'm not sure about this last bit.

IMO you can set sg_policy->need_freq_update even in the "fast switch"
case to start with and special case it in the future if that turns out
to be problematic.  That is, unless you have data indicating that it
already is problematic, of course. :-)

> ---
>  kernel/sched/cpufreq_schedutil.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> index 7936f54..ca6ce72 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -273,6 +273,14 @@ static void sugov_update_single(struct update_util_data *hook, u64 time,
>         sugov_set_iowait_boost(sg_cpu, time);
>         sg_cpu->last_update = time;
>
> +       /*
> +        * Make sugov_should_update_freq() ignore the rate limit when DL
> +        * has increased the utilization.
> +        */
> +       if ((cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl) &&
> +                       !(sg_policy->policy->fast_switch_enabled))
> +               sg_policy->need_freq_update = true;
> +
>         if (!sugov_should_update_freq(sg_policy, time))
>                 return;
>
> @@ -354,6 +362,14 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time,
>
>         raw_spin_lock(&sg_policy->update_lock);
>
> +       /*
> +        * Make sugov_should_update_freq() ignore the rate limit when DL
> +        * has increased the utilization.
> +        */
> +       if ((cpu_util_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->util_dl) &&
> +                       !(sg_policy->policy->fast_switch_enabled))
> +               sg_policy->need_freq_update = true;
> +
>         sugov_get_util(sg_cpu);
>         sg_cpu->flags = flags;
>
> --
> 2.7.4
>