The linux documentation of the variable sysfs
Maximum frequency the CPUs belonging to this policy are allowed to be running at (in kHz).
This attribute is read-write and writing a string representing an integer to it will cause a new limit to be set (it must not be lower than the value of the
My perception of the above was that I can use the following command
$ echo 2133000 >/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
to indicate to the cpufreq governer that I desire cpu0 to be run at maximum 2133Mhz. After having set the value I can check it being set via
$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
which indeed yields 2133000
Now here comes the strange part, which prompts me to pose this question here:
During the executing of a cpu intensive task (e.g. a kernel build) I check the value in
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq and it reports 1199000, a much lower frequency.
Now I am puzzled: who did change the value? the cpufreq governer?
update/info to commends
dmesgdoes not show any throttling messages
make -j4was used so to use 4 four pipelines of the intel cpu (
model name : Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz)
Linux work 4.18.3-arch1-1-ARCH #1 SMP PREEMPT Sat Aug 18 09:22:54 UTC 2018 x86_64 GNU/Linuxhence my arch linux stock kernel
- cpufreq governer is
/sys/devices/system/cpu/cpu0/cpufreq/bios_limittells 2666000 which as I would expect the max freq of the cpu. (Should I check this value during cpu stress, or in idle??)
The laptop is a Lenovo Thinkpad X201t (tablet) model, whith the mains adapter being the original one supplied to the model at purchase. However I have temporarily switched the mains power supply adapter with another one and will report results.
To be absolutely clear. The value of
scaling_max_freq is restored after the high cpu load task has ended. In "almost idle" state it again tells me the
2133000 originally set.