Messages in this thread | | | Subject | Re: [PATCH] Revert "cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo" | From | Srinivas Pandruvada <> | Date | Mon, 06 Aug 2018 09:49:29 -0700 |
| |
On Mon, 2018-08-06 at 10:30 +0200, Rafael J. Wysocki wrote: > On Sat, Aug 4, 2018 at 7:31 PM, Gabriele Mazzotta > <gabriele.mzt@gmail.com> wrote: > > On 04/08/2018 17:29, Gabriele Mazzotta wrote: > > > This change does not take into account that some BIOSes change > > > MSR_IA32_MISC_ENABLE_TURBO_DISABLE depending on the power source. > > > If the turbo is disabled when the system boots, policy.max_freq > > > is set to pstate.max_pstate. However, if the BIOS later enables > > > the turbo, the CPU will never be able to run at > > > pstate.turbo_pstate. > > > > > > Since now intel_pstate_set_policy() does its calculations using > > > pstate.max_freq and pstate.turbo_freq, we can always calculate > > > cpuinfo.max_freq using pstate.turbo_pstate, thus allowing system > > > with varying MSR_IA32_MISC_ENABLE_TURBO_DISABLE to run at full > > > speed when the turbo is enabled. > > Well, the problem with this approach is that always using > pstate.turbo_pstate as the max causes the governor to overestimate > the > target frequency when the turbo range is not available (the target > depends on the width of the entire available P-state range including > turbo, so if the turbo range is not available, the number take into > that computation is too large). > > Are we expected to get notified when the BIOS updates > MSR_IA32_MISC_ENABLE_TURBO_DISABLE?
Let's try this: - boot with kernel command line
intel_pstate=support_acpi_ppc dyndbg="file processor_perflib.c +p" dyndbg="file intel_pstate.c +p"
and send dmesg after you change power sources.
- Also try with intel_pstate=disable dyndbg="file processor_perflib.c +p"
and send dmesg.
Thanks, Srinivas
| |