linux-kernel - Re: [RFC PATCH 0/3] sched: delayed thread migration

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:   Wed, 21 Oct 2020 09:26:12 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Redha Gouicem <redha.gouicem@...il.com>
Cc:     julien.sopena@...6.fr, julia.lawall@...ia.fr,
        gilles.muller@...ia.fr, carverdamien@...il.com,
        jean-pierre.lozi@...cle.com, baptiste.lepers@...ney.edu.au,
        nicolas.palix@...v-grenoble-alpes.fr,
        willy.zwaenepoel@...ney.edu.au,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Iurii Zaikin <yzaikin@...gle.com>,
        Qais Yousef <qais.yousef@....com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrey Ignatov <rdna@...com>,
        "Guilherme G. Piccoli" <gpiccoli@...onical.com>,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] sched: delayed thread migration

On Tue, Oct 20, 2020 at 05:44:38PM +0200, Redha Gouicem wrote:
> 
> The first patch of the series is not specific to scheduling. It allows us
> (or anyone else) to use the cpufreq infrastructure at a different sampling
> rate without compromising the cpufreq subsystem and applications that
> depend on it.

It's also completely redudant as the scheduler already reads aperf/mperf
on every tick. Clearly you didn't do your homework ;-)

> The main idea behind this patch series is to bring to light the frequency
> inversion problem that will become more and more prominent with new CPUs
> that feature per-core DVFS. The solution proposed is a first idea for
> solving this problem that still needs to be tested across more CPUs and
> with more applications.

Which is why schedutil (the only cpufreq gov anybody should be using) is
integrated with the scheduler and closes the loop and tells the CPU
about the expected load.