So I came across a video of titus from ~3 years ago and the comments on it are overwhelmingly positive and thanking him for giving them hours of more battery life
Where he basically shares “auto-cpufreq”
If it is that great, why not include it in a guide officially(/or in the kernel somehow) to help manage and prolong battery life.
So my question is if any of you have personal experience with it and has it been helpful to you or what do you think about it ?
(I just found it and was thinking of installing it)
I may have a look at it too …
1 Like
I know Chris Titus, good guy. Yes, for most of us this would feel a bit obvious. But he’s pretty results driven, so if he is suggesting the usage of auto-cpufreq, he genuinely believes this is worthwhile from his perspective.
Last I checked, Chris hasn’t tested any of Framework Laptops. Also, his view of how to get the best battery life and mine, likely differ some. But if he is suggesting you try it, go for it. But we have existing guidance in place at the moment.
I am also in process of validating the use of TuneD as my friends at UBlue/Bluefin have been dipping their toes into those waters with their Intel Framework laptops. They had some interesting results and have encouraged me to explore this further.
4 Likes
As far as I know, since that video was made both Intel and AMD have published their own platform driven frequency scaler, and distros have defaulted to using them.
If you check on a modern machine that surely default to p-state.
This scaling driver also offloads preferred core support which is important for big.LITTLE, and dual ccd designs, which are becoming more popular.
Unless you want to tinker and test out the optimal settings for each situation and automate it, or force a specific behavior, it’s generally best to use p-state.
It’s been a long time but iirc p-state in it’s early incarnations were based on auto-cpufreq which is based on ondemand.
2 Likes
