linux-kernel - Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle

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: <20171030120709.GO4240@vireshk-i7>
Date:   Mon, 30 Oct 2017 17:37:09 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Joel Fernandes <joelaf@...gle.com>
Cc:     linux-kernel@...r.kernel.org,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Cc: Srinivas Pandruvada" <srinivas.pandruvada@...ux.intel.com>,
        "Cc: Len Brown" <lenb@...nel.org>,
        "Cc: Juri Lelli" <juri.lelli@....com>,
        "Cc: Patrick Bellasi" <patrick.bellasi@....com>,
        "Cc: Steve Muckle" <smuckle@...gle.com>,
        "Cc: Brendan Jackman" <brendan.jackman@....com>,
        "Cc: Chris Redpath" <Chris.Redpath@....com>,
        "Cc: Atish Patra" <atish.patra@...cle.com>,
        "Cc: Dietmar Eggemann" <dietmar.eggemann@....com>,
        "Cc: Vincent Guittot" <vincent.guittot@...aro.org>,
        "Cc: Morten Ramussen" <morten.rasmussen@....com>,
        "Cc: Frederic Weisbecker" <fweisbec@...il.com>,
        "Cc: Thomas Gleixner" <tglx@...utronix.de>,
        "Cc: EAS Dev" <eas-dev@...ts.linaro.org>,
        "Cc: Android Kernel" <kernel-team@...roid.com>
Subject: Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about
 to idle

On 28-10-17, 02:59, Joel Fernandes wrote:
> Updating CPU frequency on last dequeue of a CPU is useless. Because the
> utilization since CPU came out of idle can increase till the last dequeue, this
> means we are requesting for a higher frequency before entering idle which is
> not very meaningful or useful. It causes unwanted wakeups of the schedutil
> governor kthread in slow-switch systems resulting in large number of wake ups
> that could have been avoided. In an Android application playing music where the
> music app's thread wakes up and sleeps periodically on an Android device, its
> seen that the frequency increases slightly on the dequeue and is reduced when
> the task wakes up again. This oscillation continues between 300Mhz and 350Mhz,
> and while the task is running, its at 300MHz the whole time. This is pointless.
> Adding to that, these are unnecessary wake ups. Infact most of the time when
> the sugov thread wakes up, all the CPUs are idle - so it can hurt power by
> disturbing the cluster when it is idling.
> 
> This patch prevents a frequency update on the last dequeue. With this the
> number of schedutil governor thread wake ups are reduces more than 2 times
> (1389 -> 527).
> 
> Cc: Rafael J. Wysocki <rjw@...ysocki.net>
> Cc: Viresh Kumar <viresh.kumar@...aro.org>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Signed-off-by: Joel Fernandes <joelaf@...gle.com>
> ---
>  kernel/sched/fair.c  | 25 ++++++++++++++++++++++---
>  kernel/sched/sched.h |  1 +
>  2 files changed, 23 insertions(+), 3 deletions(-)

So you are doing this only for CFS, isn't that required for RT/DL as
well?

Also, this more looks like a policy decision. Will it be better to
put that directly into schedutil? Like this:

        if (cpu_idle())
                "Don't change the freq";

Will something like that work?

-- 
viresh