retitle 617732 fails to set scaling_max_freq if a non-default value was
previously set
thanks
Hi,
Ritesh Raj Sarraf wrote (11 Mar 2011 05:59:21 GMT) :
> Can you just test this first with the exec-commands module in
> laptop-mode-tools?
> If that works, then we will investigate further.
I conducted a few more tests.
First, please note it appears to me that when switching to the
performance governor, without any userspace cpufreq management tool
being used, a previously set non-default scaling_max_freq is restored:
use performance governor
set scaling_max_freq to a non-default F value
switch to ondemand governor
switch back to performance governor
=> scaling_max_freq is set back to F by the kernel.
This kernel feature was interfering with my previous test suite,
and we should take it into account from now on.
,----
| 1. Setting scaling_max_freq *after* the governor using cpufreq-set
`----
The laptop-mode-tools cpufreq management is disabled.
Using this exec-commands configuration:
BATT_EXEC_COMMAND_0="cpufreq-set --cpu 0 --governor ondemand"
LM_AC_EXEC_COMMAND_0=""
NOLM_AC_EXEC_COMMAND_0="cpufreq-set --cpu 0 --governor performance"
BATT_EXEC_COMMAND_1="cpufreq-set --cpu 0 --max 1999000"
LM_AC_EXEC_COMMAND_1=""
NOLM_AC_EXEC_COMMAND_1="cpufreq-set --cpu 0 --max 2667000"
(I added such commands for every CPU HT pseudo-core I have.)
=> Perfectly works.
,----
| 2. Setting scaling_max_freq *before* the governor using cpufreq-set
`----
The laptop-mode-tools cpufreq management is disabled.
Using this exec-commands configuration:
BATT_EXEC_COMMAND_0="cpufreq-set --cpu 0 --max 1999000"
LM_AC_EXEC_COMMAND_0=""
NOLM_AC_EXEC_COMMAND_0="cpufreq-set --cpu 0 --max 2667000"
BATT_EXEC_COMMAND_1="cpufreq-set --cpu 0 --governor ondemand"
LM_AC_EXEC_COMMAND_1=""
NOLM_AC_EXEC_COMMAND_1="cpufreq-set --cpu 0 --governor performance"
(I added such commands for every CPU HT pseudo-core I have.)
=> Perfectly works.
,----
| 3. Setting scaling_max_freq *before* the governor using the cpufreq module
`----
exec-commands disabled, original 1.57-1 cpufreq module.
I set real frequencies instead of fastest/slowest in order to zoom in
on the actual problem. These frequencies are the default ones the
kernel sets at boot time when no userspace cpufreq management tool is
used.
BATT_CPU_MAXFREQ=2667000
BATT_CPU_MINFREQ=1199000
BATT_CPU_GOVERNOR=ondemand
BATT_CPU_IGNORE_NICE_LOAD=1
LM_AC_CPU_MAXFREQ=2667000
LM_AC_CPU_MINFREQ=1199000
LM_AC_CPU_GOVERNOR=performance
LM_AC_CPU_IGNORE_NICE_LOAD=0
NOLM_AC_CPU_MAXFREQ=2667000
NOLM_AC_CPU_MINFREQ=1199000
NOLM_AC_CPU_GOVERNOR=performance
NOLM_AC_CPU_IGNORE_NICE_LOAD=0
=> This works perfectly if, and only if, scaling_max_freq was never
changed from the default value since the system has been started.
If scaling_max_freq was previously changed to a non-default value,
e.g. by setting BATT_CPU_MAXFREQ=1999000, when plugging AC in,
scaling_max_freq is wrongly set to 2666000 instead of the
configured 2667000. It seems to me the kernel setting restore
feature, that happens after laptop-mode-tools has set
scaling_max_freq, is the one that sets this undesired value.
,----
| 4. Setting scaling_max_freq *after* the governor using the cpufreq module
`----
Same configuration as in #3, but patched laptop-mode-tools 1.57-1's
cpufreq module to set scaling_max_freq after the governor.
=> This works perfectly if, and only if, scaling_max_freq was never
changed from the default value since the system has been started.
If scaling_max_freq was previously changed to a non-default value,
when plugging AC in, a seemingly random subset of CPU HT
pseudo-cores' scaling_max_freq are wrongly set to 2666000
(presumably by the kernel restore feature), some are correctly set
to 2667000 (presumably by cpufreq doing what it has been instructed
to do). This random behaviour seems to me like the race condition I
initially worked around using "sleep 1".
As reported previously, inserting "sleep 1" between setting
scaling_max_freq and setting the governor makes things work
reliably.
,----
| Conclusions
`----
The sysfs cpufreq interface seems not able to guarantee us settings
are applied immediately. This might be considered as a kernel bug; on
the other hand, cpufreq-set does work properly in any case I have
tested (#1 and #2), so we can also consider the laptop-mode-tools'
cpufreq module has wrong expectations about how this sysfs interface
is supposed to work.
I can see two possible solutions to this problem:
A. Use cpufreq-set rather than the sysfs interface to set
cpufreq-related values.
B. Keep using the sysfs interface, but re-order the values setting
and insert some small sleep time between changing the governor and
setting scaling_max_freq (as I suggested in my initial bugreport).
B annoyingly slows down the laptop-mode-tools' mode switch; moreover,
it seems fragile to me as I don't know how the sleep time duration
could be chosen other than based on experiments. I therefore suggest
implementing my A proposal.
What do you think?
Bye,
--
intrigeri <[email protected]>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Then we'll come from the shadows.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
