Daemon to set scaling_max_freq according to CPU temperature

[Zucca]

Ok. That was what I've been using, so that's good.

However I get crashes. I'll start the daemon on foreground to see if it tells something upon crashing...
_________________
..: Zucca :..

[logrusx]

[Zucca]

[pa4wdh]

[Zucca]

[logrusx]

[Zucca]

[pa4wdh]

From our discussion here we can see points-of-view differ on this matter, so an option to control this behavior seems the way to go. My idea is to add an option to keep things as-is on a normal exit (so it sticks to whatever the program set as last value), on an abnormal exit (failure of some kind) i think it should always do some kind of failsafe.

Would that work for you?
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[Zucca]

[pa4wdh]

Pleasing everyone indeed leads to a lot of options. That's why i'm looking for something that's easy to implement and does enough to help with the issues.

Your suggestion looks nice, but with current parameter parsing this isn't easy to do. I'm using getopt (see man 3 getopt) which can handle simple switches (like -m) and arguments which take a single argument (like -i <sensor>).
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[Zucca]

Then maybe just implement "exit governor" and "failsafe governor" and just let frequency go as high as the governor allows?
Failsafe governor being 'powersave' by default and exit governor being the one being used when running cputemp2maxfreq by default.
_________________
..: Zucca :..

[pa4wdh]

I just updated the repo (no ebuild yet). Most important changes:
- Added the -k option as proposed a few posts back to keep the last state instead of setting the lowest possible frequency
- Added multi-CPU support (also makes it a tiny bit more efficient on single-CPU machines), added -P parameter for that
- Added a manpage
- Added -Wall and -Werror to CFLAGS in the Makefile and fixed the errors it came up with
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[logrusx]

Great!

I haven't used it for a while, no big builds necessitated it, but will report when I use it. For now I just started it to se how it behaves. No surprises.

Best Regards,
Georgi

[pa4wdh]

I've just made a new release with a new ebuild.

I've added some more compiler flags to catch coding errors, and made it more explicit the code is GPL3 (this was already stated in the ebuild, but now it contains the license and copyright headers).

Ebuild and manifest can be found here: https://code.pa4wdh.nl.eu.org/tools/cputemp2maxfreq/tree/gentoo
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[logrusx]

Hello, is your daemon compatible with 6.1 kernels? It says invalid CPU data and I was wondering if it's my mistake.

Best Regards,
Georgi

[pa4wdh]

I am not aware of issues with 6.1 kernels, I've run it myself on 6.1 and now on 6.6 kernels.

What values does it report?

These are the hardcoded limits (from cputemp2maxfreq.h):

[logrusx]

It was my mistake, sorry. Amd-pstate driver requires a boot command line argument and while investigating my resume from sleep issue, I have somehow lost it. I just found out and was about to delete mu post but you were faster :)

Best Regards,
Georgi

[Zucca]

I'll test the 0.6 version this weekend.
All the published versions are on my repo as well. ;)
_________________
..: Zucca :..

[pa4wdh]

@logrusx: Good you found the issue.

@Zucca: Thanks for the update.
I'm working on a new one, primarily with some small (bug)fixes.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[pa4wdh]

I just pushed some changes to my repo, including a new ebuild.

Just some small changes this time, no new features.
The most notable change is that scaling_max_freq is now read every poll interval (just like the temperature and current frequency), in previous releases this was done only after changing it. This change means is deals better with situations where something else has changed scaling_max_freq between polls.

I was in doubt if i should call it 0.6.1 or 0.7 because the changes are so small, but since this is a very small project anyway i decided to call it 0.7 .
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

[Zucca]

Somewhat off topic:

Does intel CPUs generally benefit more of this daemon?
I haven't dug much info, but looking at htop and other sysmons on my boxes, it looks like most intel CPU can change cpu frequency very gradually, instead of rough steps.
My Ryzen based laptop has the following:

Code:

available frequency steps:  2.10 GHz, 1.70 GHz, 1.40 GHz

, only three stages of CPU frequency.
I've been toying with an idea of building some µATX or even miniITX workstation. I'll probably place some high TDP CPU there, and would like to use cputemp2maxfreq to limit the performance when on "silent-mode".
So would choosing Intel be a better choice compared to AMD?

_________________
..: Zucca :..

[logrusx]

It looks like you're using ACPI-cpufreq. Afair it provides only 3 states.

Best Regards,
Georgi

[Zucca]

SPLIT: amd-pstate conversation continues here.
_________________
..: Zucca :..