How would you change cpu governor permanently?

I wonder how would you change CPU governor on Leap permanently?
I know how to do change it manually for duration of the session:

echo *governor* | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null
  • but I’m not sure what would be a best way to set it up so it would survive reboots :smiley: .
    By default it is set to powersave, but “performance” makes more sense in my use case.

That is something set in the running kernel. You cannot make that permanent (except maybe by compiling a changed kernel), but you can set it at every boot.

That is in these days done by creating a systemd service.

Create a file /etc/systemd/system/cpugov.service (or another name before the .). Contents something like:

[Unit]
Description=Change CPU governor

[Service]
Type=forking

ExecStart=echo *governor* | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null

[Install]
WantedBy=multi-user.target

Adapt the ExecStart statement to need (do you realy need the tee there?)
Also you might want to have it at a different target.

Enable so it will be used at boot:

systemctl enable cpugov.service

Start manually:

systemctl start cpugov.service

Ask status:

systemctl status cpugov.service

To understand more:

man systemd
man systemctl

The traditional way to persist core system modifications like custom proc settings is to either modify the /etc/sysctl file or do one of the methods described in the comments of the /etc/sysctl file.

Long ago,
I wrote an article that describes doing this to persist modifications to the default TCP/IP buffer settings

https://sites.google.com/site/4techsecrets/optimize-and-fix-your-network-connection/tcp-buffer-re-sizing/persisting-tcp-buffer-and-congestion-control-algorithm-changes

Yes, this is pre-systemd, but generally speaking I would still do the same for its simplicity compared to creating a systemd service for anything that modifies the core system at a low level. Although I haven’t checked, I would also expect that any such changes would be implemented very early in the boot process and before anything invoked by systemd can start up.

Note that both the sysctl method and systemd don’t actually write changes to a system’s defaults, in both cases a custom configuration is read and implemented on each bootup.

TSU

in all honesty - I don’t know. I’m just blatantly copying and pasting command that from what I know does the trick without really understanding how it works :frowning: .
I’ve tried :

echo performance >/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

but I got this error:

bash: /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor: ambiguous redirect

That is a rather dangerous starting point :frowning:

logicaly, because cpu* expands into several items. Which one to choose (in human terms), complete nonsense (to the shell).

I have no experience with this at all, but I see that, on my system(!), there is a /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor and a
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor. Thus for every CPU one.

I guess the author of the text you try to copy/paste assumed some understanding by the reader to interprete cpu* as “for every cpu”.

Mind that I am only making comments on your shell statments. Not on your original questions "
How would you change cpu governor permanently?". (My answer to that would be: I would not, but that would not help you at all).

yeah , I know - but as I can’t find an easier way to do it I have to use what works. Really I’m not an IT specialist, as much as I’d love to understand the system a bit more (and I’m learning) , I have to focus first on things that pays for my bills. Which in this case means having a working desktop for design work and a bit of rendering.
There should be an easier way to do it for regular Joe like me (as default setting is not good for me - I need to every bit of power I can get, every second shoved from rendering a frame quickly adds up when you render an animation).
I understand what * means - and I hoped that system would understand it as well (exactly like it would understand if you use it in ls command for example - ls whateeverterm*).
With tee it works as expected and changes cpu governor on all cores with a single command. It would so bad if it would have to be repeated for every core.

I’ve tried the systemd approach and sadly it does not work. I get:

The unit files have no [Install] section. They are not meant to be enabledusing systemctl.

Which is puzzling for me as there is this part:

[Install]
WantedBy=multi-user.target

is there anything more I should add?
I’ve also found this:

Maybe that would be a solution? There is cpupower package but I don’t see a service file for it.

Hi
Use the cpupower command?


cpupower -c all frequency-set -g performance
cpupower -c all frequency-info |grep "governor \""

The first one sets all the cpu’s available to performance, the other just show what it is… so depending on what governors you have you can change it back.

Perhaps you might want to describe what your trying to achieve that needs you to set the performance governor?

Hi
OK rendering… so what GPU are you using? Oh the above command needs to be done as root…

PS, only a couple of weeks left for Leap 42.2… in your busy schedule consider a backup and upgrade :wink:

First, please look at the other suggestions/advice given above (as you alraedy do). I will continue a bit in the background on this post.

Please do post complete sequencies, not only the error or (part of) output. That is the prompt and command (the line before the output), the output and the line after (which will contain the prompt again). That will show us who you are, where yoyu wwre, what you did and waht you got and that it is complete. Only so can we sse what you saw.

Now we have an error message without context :(.

Also, do not post just that part that you think is important of the systemd file. Post it complete. It isn’t that big! It is the only way we may see if it is correct.

And yes, the tee will address the several instances of cpu*. That is correct. When you want to know what tee does:

man tee

I only asked you in my first post above a clarification in the assumption that you knew what you wetre doing… That was not meant to confuse you.

Hi
And a systemd service file…


# /etc/systemd/system/cpugov.service
#

[Unit]
Description=Change CPU governor

[Service]
Type=oneshot
ExecStart=/usr/bin/sh -c "/usr/bin/cpupower -c all frequency-set -g performance"

[Install]
WantedBy=multi-user.target

As root user;


systemctl status cpugov
systemctl start cpugov
systemctl status cpugov

If all ok, enable;
systemctl enable cpugov

Looks like what is asked and much more is covered in the Linux Arc h Wiki (to my eye, all applies to openSUSE as well)

https://wiki.archlinux.org/index.php/CPU_frequency_scaling

If there is any question related to the article, you can post again.

TSU

Malcom, you’re a star. That did the trick. Initially I had problems with it - when I realized that I need to reboot for systemd to see a new service file.

Hope you and hcvv haven’t taken my comment about time being limiting factor the wrong way. What I’ve been trying to say is that I’ve reached a point I had to come to grips with the fact I can’t be expert in everything I want to. That’s not humanely possible.
Things like this is an expert knowledge. It’s not the kind of functionality that’s easily discoverable and tweakable by regular user. So regular Joe may struggle with it, while it is probably easy for an IT expert. In similar fashion it may be easy for me to understand and tweak draft angle on a production part in Rhino, while I fully understand for most of the people that sounds gibberish :smiley: .

@tsu2 : yeah, Arch Wiki is an awesome resource. It’s the one where I’ve learned howto set the governor non-permanently (I see it has changed a bit since I’ve looked it up last time). But they lost me when it came to making those permanent (udev, scaling driver).

*side note - I see I’ve marked the topic incorrectly. I’m already on 42.3, not 42.2 :D.

Again thank you folks! You rock.