22 Oct
2017
22 Oct
'17
2:59 p.m.
Hello,
I have set the scaling governor to 'performance' by doing:
echo -n performance
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
For all 4 CPUs.
After reboot, the scaling governor indeed shows:
% date
Sun Oct 22 08:53:49 EDT 2017
% cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance
But then shortly thereafter:
% date
Sun Oct 22 08:54:06 EDT 2017
% cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave
Which mechanism decides long after boot that the scaling governor
should be modified and how to tell it that 'powersave' is not what we
want ?
Cheers.
22 Oct
22 Oct
3:11 p.m.
On Sun, 22 Oct 2017 08:59:03 -0400, jonetsu wrote:
Sun Oct 22 08:53:49 EDT 2017
performance
Sun Oct 22 08:54:06 EDT 2017
powersave
Which mechanism decides long after boot that the scaling governor
should be modified and how to tell it that 'powersave' is not what we
want ?
Perhaps a startup script of your distro does "sleep" a "few" seconds,
before it switches to "powersave".
Does it stay with "performance", if you manually switch to
"performance"
after it automatically became "powersave"
--
Guerilla Open Access Manifesto:
https://archive.org/stream/GuerillaOpenAccessManifesto/Goamjuly2008_djvu.txt
4:19 p.m.
On Sun, 22 Oct 2017 15:11:40 +0200
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
Does it stay with "performance", if you
manually switch to
"performance" after it automatically became "powersave"
Yes it does. I upgraded to a 'brand new' Linux Mint 18 recently and
been logging as root after every boot, wait for the system to switch to
'powersave' then execute a script that sets the scaling governors
to 'performance' where they stay as such thereafter.
Since the behaviour is steady, I could have a startup script that waits
approx. 30 seconds and then sets 'performance'. That would very
likely do it but it's not clean. I'd rather know which process does
this and fix it there. I'll take a look at the init scripts or
whatever takes this role in recent Linux distros these days but for
now, I have to install some windows. That is, real ones, in our
house :) Will take a look later on today.
Cheers.
5:35 p.m.
Probably you need to purge cpufrequtils, since it seems to contain
relevant scripts. Keep in mind that systemd-sysv-generator handles init
scripts.
[root@archlinux rocketmouse]# systemd-nspawn -qD /mnt/moonstudio
[root@moonstudio ~]# apt update
[root@moonstudio ~]# apt install cpufrequtils
[root@moonstudio ~]# dpkg -L cpufrequtils | grep init.d/
/etc/init.d/loadcpufreq
/etc/init.d/cpufrequtils
[root@moonstudio ~]# apropos systemd-sysv-generator
systemd-sysv-generator (8) - Unit generator for SysV init scripts
[root@moonstudio ~]# apt purge cpufrequtils libcpufreq0
[root@moonstudio ~]# lsb_release -dc
Description: Ubuntu 16.04.3 LTS
Codename: xenial
I don't know if there are other packages provided by Ubuntu
repositories and/or Mint repositories, but cpufrequtils looks like a
reasonable culprit.
5:38 p.m.
I don't know if there are other packages provided by Ubuntu
^related ;) (there are a few unrelated
packages available by the
repositories :D)
repositories and/or Mint repositories, but cpufrequtils looks like a
reasonable culprit.
7:44 p.m.
On 10/22/2017 02:59 PM, jonetsu wrote:
Which mechanism decides long after boot that the
scaling governor
should be modified and how to tell it that 'powersave' is not what we
want ?
It might be /etc/init.d/ondemand. And because ondemand is not available
on your system it switches to powersave. You can disable this init
script with 'systemctl disable ondemand'.
Best,
Jeremy
23 Oct
23 Oct
8:57 p.m.
On Sun, 22 Oct 2017, jonetsu wrote:
powersave
powersave
powersave
powersave
Which mechanism decides long after boot that the scaling governor
should be modified and how to tell it that 'powersave' is not what we
want ?
Something I have been complaining about for years (won't fix). /etc/rc5.d
has a link called S01ondemand, The README says:
"To disable a service in this runlevel, rename its script in this
directory so that the new name begins with a 'K' and a two-digit
number, and run 'update-rc.d script defaults' to reorder the scripts
according to dependencies."
So rename S01ondemand to K01ondemand and run (sudo) update-rc.d script
defaults. That script has a 60 second delay in it (why?). If you have
installed cpufrequtils there should be a file called S03cpufrequtils in
that directory and look in /etc/default/ for cpufrequtils in there which
should have 1 line
GOVERNOR="performance"
All done... you don't need a custom script or anything.
--
Len Ovens
www.ovenwerks.net
10 Nov
10 Nov
11:50 p.m.
On Sun, 22 Oct 2017 08:59:03 -0400
jonetsu <jonetsu(a)teksavvy.com> wrote:
% cat
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave
For completion's sake, in case someone searches this later on, the
ondemand script was the culprit. Keeping in mind the least
modifications done to the system the better, I simply put a 'return 0'
at the beginning of the script which is located in /etc/init.d/ondemand.
Cheers !
2571
days inactive
2590
days old
linux-audio-user@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Jeremy Jongepier -
jonetsu -
Len Ovens -
Ralf Mardorf