Add dynamic SAV daemon - workload-dependent power saver adjustments

[Mylinde]

Your question in was

Maybe I should introduce more aggressive defaults ... What do you think?

I think this is a good idea. It could be a "smart" or "intelligent" way with a dynamic SAV daemon - workload-dependent power saver adjustments. I’ve given it some thought and created an initial function.

Logging is enabled and can be checked with:

sudo tail -f /tmp/dyn-saver.log

Features:

• Background daemon monitoring CPU load in battery mode
• Dynamically adjusts platform profile, CPU energy policy, PCIE ASPM
• Three workload states: low (<=30%), med (30-60%), high (>=60%)
• Auto-detects available SAV profile from system capabilities
• Hysteresis and minimum delay to prevent flapping

Configuration:

• SAV_DYNAMIC_ENABLE: Enable/disable feature (default: disabled)
• SAV_DYNAMIC_INTERVAL: Sampling interval in seconds (default: 5)
• SAV_DYNAMIC_SAMPLES: Moving average window size (default: 3)
• SAV_DYNAMIC_THRESHOLDS: Low/high CPU % thresholds (default: 30,60)
• SAV_DYNAMIC_HYSTERESIS: Hysteresis % (default: 5)
• SAV_DYNAMIC_MIN_DELAY: Minimum delay between changes in seconds (default: 30)

Integration:

• Auto-starts with 'tlp init start' when enabled
• Auto-stops with 'tlp init stop'
• Includes full documentation in tlp.conf.in

Complements platform-profile-autodetect (PR #875) for complete adaptive power management:

1. Auto-detect best available profiles
2. Dynamically adjust based on workload

[Mylinde]

To briefly illustrate how this works, here is a log output from being on SAV profile and using the platform_profile quiet. First, normal browsing, then compilation of the scx_scheduler p2dq and finally normal browsing again.

dyn-saver

[linrunner]

@Mylinde Please don't invest any more time and effort into this. I will not be including load-dependent, dynamic profile switching in TLP. An explanation will follow.

[Mylinde]

@linrunner

Sure, just close the PR after a short explanation. If you later like to have a look at it, I will keep this for my personal use in my fork, because it is working really nice.

[Mylinde]

@linrunner

Closing this because still working on it.

[linrunner]

My view on the matter is this:

The kernel governor controls P-states based on workload, which determines performance and power consumption. This control is based on a characteristic curve, the slope of which can be adjusted using the tunables platform_profile and energy_performance_preference. Something like

$perf = f(load, tunable)$

TLP specifies the slope to the kernel by writing the tunable, and the kernel does all the work. That's TLP's basic principle, btw.

In TLP a profile switch occurs automatically depending on the power source or manually at the user's request. All profiles are well defined by the configuration and do not change intransparently.

With your "dynamic" approach, the slope also changes based on the load, resulting in a characteristic curve with two bend points. However, I do not find the technical complexity of this approach to be justified. Even using the conventional method, the kernel can always reach the minimum or maximum performance, regardless of the curve’s slope. I don't see any additional benefit regarding power consumption.

You might want to create a standalone tool for dynamic, load-based profile switching that uses existing tools (TLP, power-profiles-daemon, tuned) as a backend by controlling them via the Power Profiles D-Bus API. Check out the HoldProfile method.

The implementation of your daemon also has room for improvement:

• It is not synchronized with the rest of TLP, which risks race conditions and all sorts of strange effects.
• There is no control via systemd; if it crashes, it’s gone and no one notices. This can happen quickly with a shell script. Think about more powerful programming languages, like Python or Rust.
• The same applies to logging, which belongs in syslog or the journal instead of a file.

[Mylinde]

Thank you for your explanation. Unless I’ve overlooked something, the dynamic SAV profile is now seamlessly integrated and is working flawlessly without any race conditions. In fact, it can’t generate any race conditions because it only runs when TLP is inactive. I’ve set TLP_DEBUG=“dyn-saver” and will monitor its behavior.

I could definitely see a dedicated tool, perhaps a kind of fully dynamic, load-dependent AUTO-TLP. :)

Thank you very much for your excellent work with TLP.