linux-kernel - Re: [PATCH 0/2] intel_pstate: fix turbo not being used after a processor is rebooted

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:   Sat, 24 Dec 2022 16:28:19 -0800
From:   srinivas pandruvada <srinivas.pandruvada@...ux.intel.com>
To:     Pratyush Yadav <ptyadav@...zon.de>
Cc:     linux-pm@...r.kernel.org, "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Robert Moore <robert.moore@...el.com>,
        linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        devel@...ica.org
Subject: Re: [PATCH 0/2] intel_pstate: fix turbo not being used after a
 processor is rebooted

On Fri, 2022-12-23 at 10:10 -0800, srinivas pandruvada wrote:
> Hi Pratyush,
> 
> On Thu, 2022-12-22 at 11:39 +0100, Pratyush Yadav wrote:
> > 
> > Hi Srinivas,
> > 
> > On Wed, Dec 21 2022, srinivas pandruvada wrote:
> > > On Wed, 2022-12-21 at 16:52 +0100, Pratyush Yadav wrote:
> > > > When a processor is brought offline and online again, it is
> > > > unable to
> > > > use Turbo mode because the _PSS table does not contain the whole
> > > > turbo
> > > > frequency range, but only +1 MHz above the max non-turbo
> > > > frequency.
> > > > This
> > > > causes problems when ACPI processor driver tries to set frequency
> > > > constraints. See patch 2 for more details.
> > > > 
> I can reproduce on a Broadwell server platform. But not on a client
> system with acpi_ppc usage.
> 
> Need to check what change broke this.

When PPC limits enforcement changed to PM QOS, this broke. Previously
acpi_processor_get_platform_limit() was not enforcing any limits. It
was just setting variable. So any update done after
acpi_register_performance_state() call to pr->performance-
>states[ppc].core_frequency, was effective.

We don't really need to call
	ret = freq_qos_update_request(&pr->perflib_req,
			pr->performance->states[ppc].core_frequency *
1000);

if the PPC is not changed. When PPC is changed, this gets called again,
so then we can call the above function to update cpufreq limit.

The below change fixed for me.

diff --git a/drivers/acpi/processor_perflib.c
b/drivers/acpi/processor_perflib.c
index 757a98f6d7a2..c6ced89c00dd 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -75,6 +75,11 @@ static int acpi_processor_get_platform_limit(struct
acpi_processor *pr)
        pr_debug("CPU %d: _PPC is %d - frequency %s limited\n", pr->id,
                       (int)ppc, ppc ? "" : "not");
 
+       if (ppc == pr->performance_platform_limit) {
+               pr_debug("CPU %d: _PPC is %d - frequency not
changed\n", pr->id, ppc);
+               return 0;
+       }
+
        pr->performance_platform_limit = (int)ppc;
 
        if (ppc >= pr->performance->state_count ||

Thanks,
Srinivas

> 
> Thanks,
> Srinivas
> 
> > > 
> > > Thanks,
> > > Srinivas
> > > 
> > > > Pratyush Yadav (2):
> > > >   acpi: processor: allow fixing up the frequency for a
> > > > performance
> > > > state
> > > >   cpufreq: intel_pstate: use acpi perflib to update turbo
> > > > frequency
> > > > 
> > > >  drivers/acpi/processor_perflib.c | 40
> > > > ++++++++++++++++++++++++++++++++
> > > >  drivers/cpufreq/intel_pstate.c   |  5 ++--
> > > >  include/acpi/processor.h         |  2 ++
> > > >  3 files changed, 45 insertions(+), 2 deletions(-)
> > > > 
> > > > --
> > > > 2.38.1
> > > > 
> > > 
> > 
>