linux.git/drivers/cpufreq/intel_pstate.c, branch v4.9

cpufreq: intel_pstate: Always set max P-state in performance mode

2016-10-24T21:20:25+00:00

The only times at which intel_pstate checks the policy set for
a given CPU is the initialization of that CPU and updates of its
policy settings from cpufreq when intel_pstate_set_policy() is
invoked.

That is insufficient, however, because intel_pstate uses the same
P-state selection function for all CPUs regardless of the policy
setting for each of them and the P-state limits are shared between
them.  Thus if the policy is set to "performance" for a particular
CPU, it may not behave as expected if the cpufreq settings are
changed subsequently for another CPU.

That can be easily demonstrated by writing "performance" to
scaling_governor for all CPUs and then switching it to "powersave"
for one of them in which case all of the CPUs will behave as though
their scaling_governor were all "powersave" (even though the policy
still appears to be "performance" for the remaining CPUs).

Fix this problem by modifying intel_pstate_adjust_busy_pstate() to
always set the P-state to the maximum allowed by the current limits
for all CPUs whose policy is set to "performance".

Note that it still is recommended to always change the policy setting
in the same way for all CPUs even with this fix applied to avoid
confusion.

Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Set P-state upfront in performance mode

2016-10-21T20:18:22+00:00

After commit a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with
utilization update callbacks) the cpufreq governor callbacks may not
be invoked on NOHZ_FULL CPUs and, in particular, switching to the
"performance" policy via sysfs may not have any effect on them.  That
is a problem, because it usually is desirable to squeeze the last
bit of performance out of those CPUs, so work around it by setting
the maximum P-state (within the limits) in intel_pstate_set_policy()
upfront when the policy is CPUFREQ_POLICY_PERFORMANCE.

Fixes: a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with utilization update callbacks)
Signed-off-by: Rafael J. Wysocki 
Acked-by: Srinivas Pandruvada

cpufreq: intel_pstate: Fix struct pstate_adjust_policy kerneldoc

2016-10-12T18:58:14+00:00

It looks like the name of struct pstate_adjust_policy was updated
without updating its kerneldoc comment accordingly, so fix that
mistake.

Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Proportional algorithm for Atom

2016-10-12T18:58:13+00:00

The PID algorithm used by the intel_pstate driver tends to drive
performance to the minimum for workloads with utilization below the
setpoint, which is undesirable, so replace it with a modified
"proportional" algorithm on Atom.

The new algorithm will set the new P-state to be 1.25 times the
available maximum times the (frequency-invariant) utilization during
the previous sampling period except when the target P-state computed
this way is lower than the average P-state during the previous
sampling period.  In the latter case, it will increase the target by
50% of the difference between it and the average P-state to prevent
performance from dropping down too fast in some cases.

Signed-off-by: Rafael J. Wysocki 
Tested-by: Srinivas Pandruvada

cpufreq: intel_pstate: Clarify comment in get_target_pstate_use_performance()

2016-10-09T16:54:57+00:00

Make the comment explaining the meaning of the perf_scaled variable
in get_target_pstate_use_performance() more straightforward.

Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Fix unsafe HWP MSR access

2016-10-09T16:54:13+00:00

This is a requirement that MSR MSR_PM_ENABLE must be set to 0x01 before
reading MSR_HWP_CAPABILITIES on a given CPU. If cpufreq init() is
scheduled on a CPU which is not same as policy->cpu or migrates to a
different CPU before calling msr read for MSR_HWP_CAPABILITIES, it
is possible that MSR_PM_ENABLE was not to set to 0x01 on that CPU.
This will cause GP fault. So like other places in this path
rdmsrl_on_cpu should be used instead of rdmsrl.

Moreover the scope of MSR_HWP_CAPABILITIES is on per thread basis, so it
should be read from the same CPU, for which MSR MSR_HWP_REQUEST is
getting set.

dmesg dump or warning:

[   22.014488] WARNING: CPU: 139 PID: 1 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x68/0x70
[   22.014492] unchecked MSR access error: RDMSR from 0x771
[   22.014493] Modules linked in:
[   22.014507] CPU: 139 PID: 1 Comm: swapper/0 Not tainted 4.7.5+ #1
...
...
[   22.014516] Call Trace:
[   22.014542]  [] dump_stack+0x63/0x82
[   22.014558]  [] __warn+0xcb/0xf0
[   22.014561]  [] warn_slowpath_fmt+0x4f/0x60
[   22.014563]  [] ex_handler_rdmsr_unsafe+0x68/0x70
[   22.014564]  [] fixup_exception+0x39/0x50
[   22.014604]  [] do_general_protection+0x80/0x150
[   22.014610]  [] general_protection+0x28/0x30
[   22.014635]  [] ? get_target_pstate_use_performance+0xb0/0xb0
[   22.014642]  [] ? native_read_msr+0x7/0x40
[   22.014657]  [] intel_pstate_hwp_set+0x23/0x130
[   22.014660]  [] intel_pstate_set_policy+0x1b6/0x340
[   22.014662]  [] cpufreq_set_policy+0xeb/0x2c0
[   22.014664]  [] cpufreq_init_policy+0x79/0xe0
[   22.014666]  [] ? cpufreq_update_policy+0x120/0x120
[   22.014669]  [] cpufreq_online+0x406/0x820
[   22.014671]  [] cpufreq_add_dev+0x5f/0x90
[   22.014717]  [] subsys_interface_register+0xb8/0x100
[   22.014719]  [] cpufreq_register_driver+0x14c/0x210
[   22.014749]  [] intel_pstate_init+0x39d/0x4d5
[   22.014751]  [] ? cpufreq_gov_dbs_init+0x12/0x12

Cc: 4.3+  # 4.3+
Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Rafael J. Wysocki

Merge branch 'pm-cpufreq-sched' into pm-cpufreq

2016-10-01T23:42:33+00:00

cpufreq: intel_pstate: Add io_boost trace

2016-09-16T21:55:30+00:00

Add io_boost percent to current pstate_sample tracepoint.

Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Use IOWAIT flag in Atom algorithm

2016-09-14T00:28:13+00:00

Modify the P-state selection algorithm for Atom processors to use
the new SCHED_CPUFREQ_IOWAIT flag instead of the questionable
get_cpu_iowait_time_us() function.

Signed-off-by: Rafael J. Wysocki

intel_pstate: constify local structures

2016-09-13T00:40:24+00:00

For structure types defined in the same file or local header files, find
top-level static structure declarations that have the following
properties:
1. Never reassigned.
2. Address never taken
3. Not passed to a top-level macro call
4. No pointer or array-typed field passed to a function or stored in a
variable.
Declare structures having all of these properties as const.

Done using Coccinelle.
Based on a suggestion by Joe Perches .

Signed-off-by: Julia Lawall 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki