Bug 200759 - Incorrect max CPU frequency when the BIOS changes the availability of the turbo at runtime
Summary: Incorrect max CPU frequency when the BIOS changes the availability of the tur...
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Power Management
Classification: Unclassified
Component: intel_pstate (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Chen Yu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-07 22:00 UTC by Gabriele Mazzotta
Modified: 2019-03-11 01:27 UTC (History)
3 users (show)

See Also:
Kernel Version: 4.18.0-rc7
Tree: Mainline
Regression: No


Attachments
dmesg - intel_pstate=support_acpi_ppc dyndbg="file processor_perflib.c +p" dyndbg="file intel_pstate.c +p" (76.63 KB, text/plain)
2018-08-07 22:05 UTC, Gabriele Mazzotta
Details
dmesg - boot unplugged (78.19 KB, text/plain)
2018-08-08 05:09 UTC, Gabriele Mazzotta
Details
Test Patch 001 to try (1.50 KB, patch)
2018-08-08 20:40 UTC, Srinivas Pandruvada
Details | Diff
dmesg - boot unplugged - patch 001 (79.19 KB, text/plain)
2018-08-12 12:07 UTC, Gabriele Mazzotta
Details
dmesg - boot plugged - patch 001 (76.58 KB, text/plain)
2018-08-12 12:54 UTC, Gabriele Mazzotta
Details
update cpuinfo max frequency dynamically (2.61 KB, text/plain)
2019-01-16 06:47 UTC, Chen Yu
Details
update cpuinfo max frequency for all cpus (2.17 KB, text/plain)
2019-01-22 04:51 UTC, Chen Yu
Details
Merged patches (2.55 KB, patch)
2019-01-26 10:52 UTC, Gabriele Mazzotta
Details | Diff

Description Gabriele Mazzotta 2018-08-07 22:00:09 UTC
When initialized, intel_pstate sets the maximum frequency of the CPU depending on the availability of the turbo, as indicated by MSR_IA32_MISC_ENABLE_TURBO_DISABLE.

On some systems, the BIOS changes the value of MSR_IA32_MISC_ENABLE_TURBO_DISABLE at runtime (e.g., when the power source changes), but the maximum frequency of the CPU is not updated accordingly.
Comment 1 Gabriele Mazzotta 2018-08-07 22:05:01 UTC
Created attachment 277747 [details]
dmesg - intel_pstate=support_acpi_ppc dyndbg="file processor_perflib.c +p" dyndbg="file intel_pstate.c +p"
Comment 2 Srinivas Pandruvada 2018-08-07 22:55:31 UTC
Here from the log, I see

[   14.890848] intel_pstate: cpu:0 max_perf_ratio:30 min_perf_ratio:8



# Unplug

[   25.775643] CPU 0: _PPC is 6 - frequency  limited
[   25.775660] intel_pstate: set_policy cpuinfo.max 3000000 policy->max 1700000
[   25.775666] intel_pstate: cpu:0 max_state 17 min_policy_perf:8 max_policy_perf:17
[   25.775670] intel_pstate: cpu:0 global_min:8 global_max:30
[   25.775674] intel_pstate: cpu:0 max_perf_ratio:17 min_perf_ratio:8

"REDUCED FREQUENCY ABOVE AFTER UNPLUG"


# Re-plug

[   36.979264] CPU 0: _PPC is 6 - frequency  limited
[   36.979276] intel_pstate: policy->max > max non turbo frequency
[   36.979280] intel_pstate: set_policy cpuinfo.max 3000000 policy->max 3000000
[   36.979283] intel_pstate: cpu:0 max_state 30 min_policy_perf:8 max_policy_perf:30
[   36.979286] intel_pstate: cpu:0 global_min:8 global_max:30
[   36.979289] intel_pstate: cpu:0 max_perf_ratio:30 min_perf_ratio:8

"INCREASED FREQUENCY ABOVE AFTER REPLUG"

So in this scenario it seems to work fine.

Do you have dmesg when you booted unplugged and replugged?
Comment 3 Gabriele Mazzotta 2018-08-08 05:09:13 UTC
Created attachment 277751 [details]
dmesg - boot unplugged
Comment 4 Srinivas Pandruvada 2018-08-08 20:40:25 UTC
Created attachment 277763 [details]
Test Patch 001 to try

Try this patch. Please use same kernel command line parameters as before with PPC and dyndbg.
Comment 5 Gabriele Mazzotta 2018-08-12 12:07:04 UTC
Created attachment 277823 [details]
dmesg - boot unplugged - patch 001
Comment 6 Gabriele Mazzotta 2018-08-12 12:54:39 UTC
Created attachment 277825 [details]
dmesg - boot plugged - patch 001

As the logs show, only cpu 0 is updated. This is the result:

Boot=battery, current=AC
$ grep "" /sys/devices/system/cpu/cpufreq/policy*/*_max_freq
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:1700000
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:1700000
/sys/devices/system/cpu/cpufreq/policy1/cpuinfo_max_freq:3000000
/sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq:3000000
/sys/devices/system/cpu/cpufreq/policy2/cpuinfo_max_freq:3000000
/sys/devices/system/cpu/cpufreq/policy2/scaling_max_freq:3000000
/sys/devices/system/cpu/cpufreq/policy3/cpuinfo_max_freq:3000000
/sys/devices/system/cpu/cpufreq/policy3/scaling_max_freq:3000000

Boot=AC, current=battery
$ grep "" /sys/devices/system/cpu/cpufreq/policy*/*_max_freq
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:3000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:3000000
/sys/devices/system/cpu/cpufreq/policy1/cpuinfo_max_freq:1700000
/sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq:1700000
/sys/devices/system/cpu/cpufreq/policy2/cpuinfo_max_freq:1700000
/sys/devices/system/cpu/cpufreq/policy2/scaling_max_freq:1700000
/sys/devices/system/cpu/cpufreq/policy3/cpuinfo_max_freq:1700000
/sys/devices/system/cpu/cpufreq/policy3/scaling_max_freq:1700000
Comment 7 Srinivas Pandruvada 2018-08-13 16:40:31 UTC
Need to discuss internally. The notification is arriving on one CPU only on this system.
Comment 8 Chen Yu 2018-12-27 10:54:06 UTC
(In reply to Srinivas Pandruvada from comment #7)
> Need to discuss internally. The notification is arriving on one CPU only on
> this system.
How about sending ipi to all online CPUs to update their policies?
Comment 9 Chen Yu 2018-12-28 07:34:54 UTC
Then we need to update the policies within one package for them, I'll cook a patch based on Srinivas's.
Comment 10 Chen Yu 2019-01-16 06:47:44 UTC
Created attachment 280529 [details]
update cpuinfo max frequency dynamically

Could you please check this patch works for you?
Comment 11 Gabriele Mazzotta 2019-01-19 16:42:48 UTC
cat /sys/devices/system/cpu/cpufreq/policy0/*_max_freq never terminates after changing power source (i.e., when the limit should change) using v4.20, while the other policy{1,2,3} values don't change.

It seems that the cpufreq_update_policy(cpu) call your patch adds never ends. I haven't looked at what happens exactly yet.
Comment 12 Chen Yu 2019-01-22 04:50:22 UTC
(In reply to Gabriele Mazzotta from comment #11)
> cat /sys/devices/system/cpu/cpufreq/policy0/*_max_freq never terminates
> after changing power source (i.e., when the limit should change) using
> v4.20, while the other policy{1,2,3} values don't change.
> 
> It seems that the cpufreq_update_policy(cpu) call your patch adds never
> ends. I haven't looked at what happens exactly yet.

Thanks, how about using the following one, please boot with and without:
"processor.broadcast_ppc=1" and check if it works.
Comment 13 Chen Yu 2019-01-22 04:51:09 UTC
Created attachment 280651 [details]
update cpuinfo max frequency for all cpus

Please apply this patch instead.
Comment 14 Gabriele Mazzotta 2019-01-26 10:52:50 UTC
Created attachment 280787 [details]
Merged patches

The patch I attached works. It is simply a merge of your patch and Srinivas' patch.

Both cpuinfo_max_freq and scaling_max_freq of all the CPUs are updated according to the current power source.
Comment 15 Chen Yu 2019-03-11 01:27:33 UTC
Patches from Rafael:

https://patchwork.kernel.org/project/linux-pm/list/?series=87789

Note You need to log in before you can comment on or make changes to this bug.