linux-kernel - RE: [PATCH] cpufreq: schedutil: Don't skip freq update when limits change

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] [day] [month] [year] [list]

Message-ID: <000701d547f6$5e4254f0$1ac6fed0$@net>
Date:   Wed, 31 Jul 2019 16:19:10 -0700
From:   "Doug Smythies" <dsmythies@...us.net>
To:     "'Viresh Kumar'" <viresh.kumar@...aro.org>,
        "'Rafael Wysocki'" <rjw@...ysocki.net>,
        "'Ingo Molnar'" <mingo@...hat.com>,
        "'Peter Zijlstra'" <peterz@...radead.org>
Cc:     <linux-pm@...r.kernel.org>,
        "'Vincent Guittot'" <vincent.guittot@...aro.org>,
        "'v4 . 18+'" <stable@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] cpufreq: schedutil: Don't skip freq update when limits change

On 2019.07.31 Viresh Kumar wrote:
> To avoid reducing the frequency of a CPU prematurely, we skip reducing
> the frequency if the CPU had been busy recently.
>
> This should not be done when the limits of the policy are changed, for
> example due to thermal throttling. We should always get the frequency
> within the new limits as soon as possible.
> 
> Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
> Cc: v4.18+ <stable@...r.kernel.org> # v4.18+
> Reported-by: Doug Smythies <doug.smythies@...il.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> ---
> @Doug: Can you please provide your Tested-by for this commit, as it
> already fixed the issue around acpi-cpufreq driver.
>
> We will continue to see what's wrong with intel-pstate though.

Please give me a few more hours.
I'll reply to another thread with new information at that time.

My recommendation will be to scrap this "patch2" and go back
to "patch1" [1], with a couple of modifications. The logic
of patch1 is sound.
Teaser: it is working for intel_cpufreq/schedutil, but I
have yet to test acpi-cpufreq/schedutil.

[1] https://marc.info/?l=linux-pm&m=156377832225470&w=2

... Doug