On Tue, Feb 28, 2017 at 2:14 PM, Rafael J. Wysocki <[email protected]> wrote: > From: Rafael J. Wysocki <[email protected]> > > Commit 111b8b3fe4fa (cpufreq: intel_pstate: Always keep all > limits settings in sync) changed intel_pstate to invoke > cpufreq_update_policy() for every registered CPU on global sysfs > attributes updates, but that led to undesirable effects in the > active mode if the "performance" P-state selection algorithm is > configufred for one CPU and the "powersave" one is chosen for > all of the other CPUs. > > Namely, in that case, the following is possible: > > # cd /sys/devices/system/cpu/ > # cat intel_pstate/max_perf_pct > 100 > # cat intel_pstate/min_perf_pct > 26 > # echo performance > cpufreq/policy0/scaling_governor > # cat intel_pstate/max_perf_pct > 100 > # cat intel_pstate/min_perf_pct > 100 > # echo 94 > intel_pstate/min_perf_pct > # cat intel_pstate/min_perf_pct > 26 > > The reason why this happens is because intel_pstate attempts to > maintain two sets of global limits in the active mode, one for > the "performance" P-state selection algorithm and one for the > "powersave" P-state selection algorithm, but the P-state selection > algorithms are set per policy, so the global limits cannot reflect > all of them at the same time if they are different for different > policies. > > In the particular situation above, the attempt to change > min_perf_pct to 94 caused cpufreq_update_policy() to be run > for a CPU with the "powersave" P-state selection algorithm > and intel_pstate_set_policy() called by it silently switched the > global limits to the "powersave" set which finally was reflected > by the sysfs interface. > > To prevent that from happening, modify intel_pstate_update_policies() > to always switch back to the set of limits that was used right before > it has been invoked.
Scratch this, it's too racy. I'll send a new version shortly. Thanks, Rafael
