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  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:   Fri, 20 Nov 2020 14:49:04 +0530
From:   Viresh Kumar <>
To:     Quentin Perret <>
Cc:     Peter Zijlstra <>,
        "Rafael J. Wysocki" <>,
        Ingo Molnar <>,
        Thomas Gleixner <>,
        Vincent Guittot <>,
        Morten Rasmussen <>,,,,,,
Subject: Re: [RFC] Documentation/scheduler/schedutil.txt

On 20-11-20, 09:13, Quentin Perret wrote:
> On Friday 20 Nov 2020 at 09:56:53 (+0100), Peter Zijlstra wrote:
> > On Fri, Nov 20, 2020 at 08:55:27AM +0100, Peter Zijlstra wrote:
> > >  - In saturated scenarios task movement will cause some transient dips,
> > >    suppose we have a CPU saturated with 4 tasks, then when we migrate a task
> > >    to an idle CPU, the old CPU will have a 'running' value of 0.75 while the
> > >    new CPU will gain 0.25. This is inevitable and time progression will
> > >    correct this. XXX do we still guarantee f_max due to no idle-time?
> The sugov_cpu_is_busy() logic should mitigate that, but looking at it
> again I just realized we don't apply it to the 'shared' update path. I
> can't recall why. Anybody?

t b7eaf1aab9f8bd2e49fceed77ebc66c1b5800718
Author: Rafael J. Wysocki <>
Date:   Wed Mar 22 00:08:50 2017 +0100

    cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely
    This is unlikely to be an issue on systems where cpufreq policies are
    shared between multiple CPUs, because in those cases the policy
    utilization is computed as the maximum of the CPU utilization values
    over the whole policy and if that turns out to be low, reducing the
    frequency for the policy most likely is a good idea anyway.  On
    systems with one CPU per policy, however, it may affect performance
    adversely and even lead to increased energy consumption in some cases.
    On those systems it may be addressed by taking another utilization
    metric into consideration, like whether or not the CPU whose
    frequency is about to be reduced has been idle recently, because if
    that's not the case, the CPU is likely to be busy in the near future
    and its frequency should not be reduced.


Powered by blists - more mailing lists