You are not logged in.
For some reason, on my system (using the current zen kernel) the "conservative" CPU frequency scaling governor is being selected by default. I am trying to force my system to choose the "schedutil" governor (which I read should be the default), and I am able to set this governor manually by writing to `/sys/devices/system/cpu/cpufreq/policy*/scaling_governor`, but no method of persisting this setting is effective.
First thing I tried is the tmpfiles.d method. Note well that the example in the Wiki article seems to be using an undocumented tmpfiles directive `w-` that isn't described on `systemctl-tmpfiles` manpage. I tried both with the strange minus and without it, and the method does not work. I did not create a separate file under `/etc/tmpfiles.d`, but I appended the following lines to the `local.conf` file in that directory:
w /sys/devices/system/cpu/cpufreq/policy0/scaling_governor - - - - schedutil
w /sys/devices/system/cpu/cpufreq/policy1/scaling_governor - - - - schedutil
w /sys/devices/system/cpu/cpufreq/policy2/scaling_governor - - - - schedutil
w /sys/devices/system/cpu/cpufreq/policy3/scaling_governor - - - - schedutil
w /sys/devices/system/cpu/cpufreq/policy4/scaling_governor - - - - schedutil
w /sys/devices/system/cpu/cpufreq/policy5/scaling_governor - - - - schedutil
w /sys/devices/system/cpu/cpufreq/policy6/scaling_governor - - - - schedutil
w /sys/devices/system/cpu/cpufreq/policy7/scaling_governor - - - - schedutilThis had no effect.
Second thing I tried was the udev method from the Wiki article:
/etc/udev/rules.d/50-scaling-governor.rules
-------------------------------------------------------
SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+="/bin/sh -c 'echo schedutil > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor'"
SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+="/bin/sh -c 'echo schedutil > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor'"
SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+="/bin/sh -c 'echo schedutil > /sys/devices/system/cpu/cpufreq/policy2/scaling_governor'"
SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+="/bin/sh -c 'echo schedutil > /sys/devices/system/cpu/cpufreq/policy3/scaling_governor'"
SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+="/bin/sh -c 'echo schedutil > /sys/devices/system/cpu/cpufreq/policy4/scaling_governor'"
SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+="/bin/sh -c 'echo schedutil > /sys/devices/system/cpu/cpufreq/policy5/scaling_governor'"
SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+="/bin/sh -c 'echo schedutil > /sys/devices/system/cpu/cpufreq/policy6/scaling_governor'"
SUBSYSTEM=="module", ACTION=="add", KERNEL=="acpi_cpufreq", RUN+="/bin/sh -c 'echo schedutil > /sys/devices/system/cpu/cpufreq/policy7/scaling_governor'"No effect whatsoever - after reboot the "conservative" governor comes back on all cores.
My third attempt followed the article's tip about the kernel parameter. I edited `/etc/default/grub` to add the `cpufreq.scaling_governor=schedutil` to the default kernel command line, regenerated the grub config and rebooted, to no effect whatsoever. After rebooting I could confirm that the kernel was booted with the parameter, but this had no effect whatsoever either.
That last attempt however was probably incorrect, because the parameter is apparently for the acpi_cpufreq module and should be supplied via `/etc/modprobe.d`. So in my fourth attempt I created `/etc/modprobe.d/zz-cpupower.conf`, thus named so that it would have the last word (unless I'm mistaken about how this works):
/etc/modprobe.d/zz-cpupower.conf
--------------------------------------------
options acpi_cpufreq cpufreq.default_governor=schedutilAbsolutely no effect whatsoever, zero, nada, zilch. The "conservative" governor is still set for all cores once I'm fully booted to desktop.
At this point I figured out that something must be actively setting the conservative governor later in the process, so in my fifth attempt I tried disabling things that could be doing this: I disabled cpupower-gui and cpupower-gui-helper services. Aaaaand no, that didn't help either.
I'm out of my wits here. How do I get my system to just OBEY MY UKAZ that frequency scaling governor on all cores be set to "schedutil" on boot?
SOLVED: It was `tuned` doing this. Once I disabled `tuned`, another unrelated annoyance also went away: compositor always got disabled a few seconds after logging in to desktop (but could be re-enabled manually without issues).
Last edited by Donzv (2021-08-15 18:33:52)
Offline
schedutil is the default. Are you using some power management utility like TLP or laptop-mode-tools or so which is configured to change this which will run after all your other options have already applied?
You have something™ that changes this after the system is booted, so everything you are trying here is applied before something™ is ran. You mentioned two things, in doubt post all your enabled services and maybe an entire process listing, assuming that it's something that is actively alive during the session. Maybe also just a
sudo journalctl -bwe might get a piece of audit log that allows to identify the culprit.
Last edited by V1del (2021-08-15 17:52:40)
Offline
in doubt post all your enabled services
No need to post it, but studying it did help, thanks for the idea. It was `tuned`. Looks like there is an overabundance of competing tuning daemons for linux, and I handled them like my dad used to handle "helpful toolbars" in Internet Explorer until I taught him not to ![]()
Offline