Messages in this thread | | | From | "Doug Smythies" <> | Subject | RE: [PATCH] cpufreq: schedutil: Don't skip freq update when limits change | Date | Wed, 31 Jul 2019 16:19:10 -0700 |
| |
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@vger.kernel.org> # v4.18+ > Reported-by: Doug Smythies <doug.smythies@gmail.com> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.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
| |