linux-kernel - Re: [PATCH v2 0/6] cpufreq: schedutil: fixes for flags updates

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:   Fri, 07 Jul 2017 00:26:18 +0200
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Patrick Bellasi <patrick.bellasi@....com>
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Juri Lelli <juri.lelli@....com>,
        Joel Fernandes <joelaf@...gle.com>,
        Andres Oportus <andresoportus@...gle.com>,
        Todd Kjos <tkjos@...roid.com>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>
Subject: Re: [PATCH v2 0/6] cpufreq: schedutil: fixes for flags updates

On Tuesday, July 04, 2017 06:34:05 PM Patrick Bellasi wrote:
> Each time a CPU utilisation update is issued by the scheduler a flag, which
> mainly defines which scheduling class is asking for the update, is used by the
> frequency selection policy to support the selection of the most appropriate
> OPP.
>  
> In the current implementation, CPU flags are overridden each time the scheduler
> calls schedutil for an update. Such a behavior seems to be sub-optimal,
> especially on systems where frequency domains span across multiple CPUs.
>  
> Indeed, assuming CPU1 and CPU2 share the same frequency domain, there can be
> the following issues:
>  
>  A) Small FAIR task running at MAX OPP.
>     A RT task, which just executed on CPU1, can keep the domain at the
>     max frequency for a prolonged period of time after its completion,
>     even if there are no longer RT tasks running on CPUs of its domain.
>  
>  B) FAIR wakeup reducing the OPP of the current RT task.
>     A FAIR task enqueued in a CPU where a RT task is running overrides the flag
>     configured by the RT task thus potentially causing an unwanted frequency
>     drop.
>  
>  C) RT wakeup not running at max OPP.
>     An RT task waking up on a CPU which has recently updated its OPP can
>     be forced to run at a lower frequency because of the throttling
>     enforced by schedutil, even if there are not OPP transitions
>     currently in progress.
> 
> .:: Patches organization
> ========================
>  
> This series proposes a set of fixes for the aforementioned issues and it's an
> update addressing all the main comments collected from the previous posting
> [1].

It seems to me that there is a nonzero overlap between this and the Juri's work.

If that's correct, I'd like this series to go on top of the Juri's one.

Thanks,
Rafael