If you're using Intel 8th gen or above. (7th gen supported if you manually set the flag each boot) you've got speedshift which the CPU will automatically auto scale itself. (changing the p-states)
The CPU itself can change frequencies much faster on its own instead of the software based speedstep which programs like this controlled.
This eliminates the need for an on-battery or plugged-in performance mode because it changes frequencies so fast, you're no longer losing performance by waiting for the software to speed up the cpu. So you can keep it on all the time.
For these CPUs, all this is in the kernel and enabled by default.
> This eliminates the need for an on-battery or plugged-in performance mode because it changes frequencies so fast, you're no longer losing performance by waiting for the software to speed up the cpu. So you can keep it on all the time.
Here's my /etc/rc.d/rc.local script:
#!/bin/sh
for policy in /sys/devices/system/cpu/cpufreq/policy*
do
echo "power" > "$policy"/energy_performance_preference
done
Here's available preferences:
$ cat /sys/devices/system/cpu/cpufreq/policy0/energy_performance_available_preferences
default performance balance_performance balance_power power
Basically I can choose between "performance" and "power" (low performance) modes. I'm choosing power, so my fans are silent. And they're silent indeed, no matter the load.
for no additional output, sponge over tee! sponge is useful in some cases where redirecting output is annoying, and it can construct pipelines reading/writing from the same file.
Found that one way later than I'd care to admit. I use tee $FILE > /dev/null <EOF quite often in some situations where redirects get ugly, and sponge is a nice util to tidy up the invocation.
For reference, 7th gen is Kaby Lake and 8th gen is Coffee Lake. Of course, Intel had stagnated long before so many people are still on Sky Lake (6th gen).
The patent system is so useful, charging vendors billions of dollars for implementing an idea like “use the most obvious possible power saving strategies”.
The patent system also helps small companies with little working capital get started on big, obvious, money intensive challenges without being immediately crushed by megacorps. The razor cuts both ways.
Yes, this is the truth. Look at the recent Cisco patent case. They pulled a Facebook and stole some startups IP while meeting with them. The startup won over 1.5 billion in damages, mostly because they were able to show willful infringement on Cisco's part.
most of it is brightness related thing and i understand there are various inner settings but I find them doing very little. So it usually doesn't bring value to the table.
"AMD’s Ryzen 9 3900X also has the new Collaborative Power Performance Control 2 (CPPC2) feature, which manipulates Ryzen 3000's power states from within the operating system. This is similar to Intel's Speed Shift technology and reduces power state transition latency. Ultimately, that results in a more efficient processor during all facets of operation."
Though that seems to be about boosting clocks higher clocks when it can.
> Using tools like TLP will help [...] but it also might come with its own set of problems
I recently figured out TLP was the source of a couple of irritating issues for me on an XPS 9370:
- Bluetooth audio continually cutting in and out, only when wireless module on AC "non power saving mode"!?!
- DC bias on the audio out jack, on both modes, worse on power saving. (forcing a power amp into self protect mode).
Both resolved by disabling TLP entirely. I knew TLP was not a set and forget tool, but it's easy to forget when on some machines it's fine (and necessary, especially older laptops). But then changing to a new machine where it causes lots of issues. It was a good reminder that these tools need to be used with care because they often exploit unusual hardware modes and can have strange side effects.
A similar tool to prolong laptop autonomy is XSuspender <https://kernc.github.io/xsuspender/>. It configurably SIGSTOP-s unfocused X11 applications. It is, sadly, XWindows-only.
yup, easy way to distinguish is the 90 deg angle... AFAIK only the Nazi one is 45deg. If it's 90deg it's in reference to one of the many uses in Asian cultures and religions. This really aught to be taught next to WW history in the west to ensure people properly contextualise it's use when they encounter it in the wider world.
It's pretty fucked that this isn't taught. It's not like it has to be some deep dive into the significance of the swastika in Asian culture either. Even just a couple lines in a textbook about it would be far better than nothing
Where I come from neo-nazis often try to refute allegations of spreading totalitarian ideology (punishable by a fine or up to two years in prison) by saying that they were actually referring to the original meaning.
Of course nobody is buying it, but such cases are nevertheless often dismissed.
Better than nothing but it's kind of thing people who would appreciate it would find out anyway, I feel i.e. I'm fairly well read culturally/historically but I've never really studied it formally, and I think I wouldn't be as interested if I did.
I'm curious what sticks if you are led to rather than spontaneously learning.
Unfortunately both Nazi and Asian cultures (among others) have used all possible orientations (left/right-facing and 0/45/90 degrees) throughout the history, making the distinction much harder. To this end Asian countries realized that it is much easier to not use swastika than to educate people. South Korean maps for example used swastika for Buddhist temples but now use pictorial symbols instead.
That’s really really unfair. So first west fucked up our symbol and now west won’t educate itself about the actual symbol? Swastik is such an ingrained part of my culture and religion, can’t just give it up.
IMO it's kind of understandable, at least on the individual level, that people don't know. I probably didn't know until I first travelled to Asia. However, it doesn't take a genius to realize that a map (or whatever) in an Asian country probably isn't full of Nazi symbols, or that there's probably some kind of an explanation for them.
CPUs already adjust their own frequency based on load and temperature (maybe with some help from kernel drivers). It would be nice if the README explained how this tool is different from that.
As far as I can tell, this just switches the cpufreq governor based on whether the laptop is on AC or not. Tools to do this have existed for at least a decade, and integrated into various desktop environments too, so this isn't really novel in any way.
It also suggests using "powersave" on battery, based on the old idea that lower CPU frequencies save energy. This is not a given; lower frequencies use less power but also take longer to get the same amount of work done. While the CPU is active, it is consuming static power regardless of frequency. This has gotten even more significant with newer CPUs.
What the optimal power saving config is varies from system to system. Ultimately, what you need is to actually benchmark the performance and energy consumption of your system. It's complicated and you also have to deal with things like switching latencies so the cpufreq governor and scheduler can make optimized decisions. Most PCs don't really do a good job of this at all, which is one reason why battery life can be all over the place.
Sadly, switching to the "powersave" governor may not, in fact, end up saving you power, depending on what you're doing :)
> It also suggests using "powersave" on battery, based on the old idea that lower CPU frequencies save energy. This is not a given; lower frequencies use less power but also take longer to get the same amount of work done.
Hmmmm... I've always heard from chip engineers that power consumption / heat dissipation was not linear compared to clock speed. I'd be very surprised to find a case where a linear amount of work to be done by the CPU would cause more energy consumption overall at lower clock speed then the same task ran on the same CPU in a shorter timeframe, but at a higher clock rate.
I do agree that if the task takes longer to run, there's a longer timeframe where more scheduling/switching and whatnots needs to be done, so it's not a totally linear increase in time, but can that really be sufficient to offset the energy consumption when running the CPU at an higher clock speed?
There has to be some numbers out there: it's not hard that hard to test.
EDIT: as per the other comments, googling "race to idle" and "race to sleep" which may enlighten my curious self
Power consumption through an asic is P=CfV^2 aka power is capacitance times frequency times voltage squared. So power does scale linearly with frequency.
When you gate on/off portions of a chip, you are changing the capacitance.
What that equation doesn't tell you is that the voltage necessary to make a chip run at 4GHz is higher than the voltage it needs to run at 1GHz. So in practice with real CPUs, increasing frequency also means increasing voltage, and thus power does not increase linearly. (Unless you have a chip that's configured to idle with unnecessarily high voltage.)
> Hmmmm... I've always heard from chip engineers that power consumption / heat dissipation was not linear compared to clock speed. I'd be very surprised to find a case where a linear amount of work to be done by the CPU would cause more energy consumption overall at lower clock speed then the same task ran on the same CPU in a shorter timeframe, but at a higher clock rate.
Both cases ("slower is better" and "faster is better") are true at different points on the frequency curve, because the frequency (hereafter "F") and power (hereafter "P") relationship has both linear and superlinear terms.
To a first order approximation, dynamic power (roughly the power actually used to do work) scales with F^3, but chips also have a significant static power draw as well: power they draw for just being on. Actually, the relationship is more complicated than that since static power may also depend on V, hence indirectly on frequency, but the bottom line is that as you reduce frequency to zero power use doesn't go to zero but asymptotically approaches some non-zero plateau.
So imagine a simplified CPU where we care only about the order-0 and order-3 terms, and it happens that power goes like (P in W, F in MHz):
P(F) = 2 + 1e-10*F^3
That is, this chip draws at least 2W at any frequency, plus a cubic term in F.
This gives a power curve like this [1] where I've also plotted "work vs energy" which is energy efficiency: how much computation you can do for a given energy input (this is simply F/P).
As you can see, power use increases in a cubic way to the right, but has an asymptote at 2W on the left. Work/energy has a maximum in the middle: at too low frequencies, you are doing very little work/time but paying the full 2W cost, while at the right the cubic term kills power: P increases with F^3 but work only with F. The most efficient spot is somewhere in the middle. Let's call this point Feff.
So it never really makes sense to run your CPU at less than Feff: you are less efficient and it takes longer. It can definite makes sense, however, to run your CPU at more than Feff: you use somewhat more energy but get your work done faster. People don't buy 5 GHz CPUs because they just want their work done efficiently, after all: they want it done fast too.
That's what a lot of the discussion misses: it's not a one dimensional problem that can be solved in terms of joules and MHz: it depends on your time preference too. That's why there are so many tunables, such as Intel's EPP (energy performance preference).
Different processes may have different ideal F values as well: if you have a periodic job running in the background that takes 1s of (nominal) CPU every minute, you won't care if it is on your CPU for 0.5s or 2s, as it runs on a fixed schedule anyway which is much less than a full CPU: this should run at Feff. OTOH when you are compiling a source file and twiddling your thumbs there might be a big difference between 5 and 20 seconds.
This is really only brushing the surface: there are a lot of additional considerations too: e.g., the whole chip may have a power limit, so it may not be possible to go all the way to right on the F graph, especially if multiple cores are running: even if your "performance preference" is way to the right (prefer a higher work/rate regardless of the power cost) you might get the fastest work rate by running more cores at lower F, or even one core at lower F to avoid throttling (because running at F is generally more efficient than running at F-d and F+d in a 50/50 ratio, due to the cubic term, so throttling is inherently inefficient).
> Sadly, switching to the "powersave" governor may not, in fact, end up saving you power, depending on what you're doing
Independently of whether that's true, isn't most consumer hardware (laptops) running "idle" most of the time?
Not setting "powersave" might be better if you want to compile something, transcode a video or do some machine learning and turn the machine off as soon as it's done. But that's hardly how a majority uses their devices.
> Independently of whether that's true, isn't most consumer hardware (laptops) running "idle" most of the time?
Yes, which is why you want to become idle as fast as possible - and that means running at the fastest clock speed when you need to get some work done. Otherwise you are extending the amount of the time system is not idle, which has a fixed power cost beyond the CPU cores themselves.
Here's a Lenovo power optimization guide. It's for servers, but the same principles apply to pretty much all modern systems. Spoiler alert: the "ondemand" governor has the highest energy efficiency, significantly higher than "powersave" (page 14). The newer schedutil governor (page 23) is even better, over 34% more power-efficient than powersave.
"Powersave" means saving power, it doesn't mean saving energy. Your battery holds a fixed amount of energy, not a fixed amount of power. Energy is what matters.
> "Powersave" means saving power, it doesn't mean saving energy. Your battery holds a fixed amount of energy, not a fixed amount of power. Energy is what matters.
Ignoring everything else, your battery doesn't hold a fixed amount of energy either. Or, if it does, it doesn't deliver a fixed amount. The energy you get out depends on the load. If you draw enough power that it heats the battery, you'll get less energy out. Of course, if you draw so little energy that self discharge becomes significant, you'll get less energy out.
As with the rest of the discussion, there's clearly a balance to be had, but it's hard to make the optimum choice because the systems usually don't know the load profile of (immiment) future work, and there are many systems that interact, and there may be no part of the system that has enough information to make an overall decision. That said, there's clearly been lots of progress on getting quite good results in most scenarios.
> "Powersave" means saving power, it doesn't mean saving energy.
Powersave means saving energy (for a given amount of work), despite the name. Any other behavior is a bug. It usually saves energy by running at a lower frequency, where the frequency/watt and work/joule are better (those aren't the same: there is a region where the first is better but the latter is worse, and you want to avoid that!).
"Race to sleep" isn't binary: it's not a choice between the slowest supported speed and the fastest. Rather, you can select any supported speed. The fastest speeds (usually north of 3 GHz) will almost never provide the best work/joule, regardless of whether you sleep earlier.
That's the entire governor. It sets the lowest frequency. This is the documented behavior. Not the frequency with the highest performance per watt. The lowest frequency, period.
Yes, "race to sleep" isn't binary, which is why we have smart modern governors that do a very good job at picking appropriate frequency states - but just as the highest turbo is almost always a bad idea, so is the lowest state, which is what "powersave" does. "ondemand" is more power efficient than "powersave", and "schedutil" even moreso, on modern CPUs.
Right, because the lowest supported frequency is supposed to be the most energy efficient frequency, Feff, at least on Intel chips. I.e. it is the minimum in the joules/work chart.
After all, there's no point
running at a lower frequency: those frequencies are always dominated regardless of your time/energy preference, so Intel claims to set Fmin to Feff.
So lowest freq is a good proxy for "I only care about efficiency".
That said, powersave is a bit ambiguous: it's a policy in more than one driver. For example, intel_pstate, the default recommended driver for Intel chips, has powersave and performance governors too, and there powersave is much more sophisticated and can run at high frequencies.
OK, I actually read the Lenovo paper and it seems fine.
One big difference with what I'm trying to claim is that what I'm saying considers only the power use of the CPU itself: i.e., the thing whose power use varies with frequency. From the CPU manufacturer's point of view, that's all they can really do.
The Lenovo paper is looking at total system power, and the way they calculate efficiency includes the system power in the efficiency calculation. This pushes the efficiency point well above what you'd get from looking at the CPU alone.
Both approaches are right some of the time: on a laptop where the rest of the system is running regardless, you probably want to consider only the CPU power in the efficiency calculation: if your CPU work finishes more quickly it's not going to stop the draw from the screen, wifi chip, etc.
OTOH on a server if you size your fleet based on the total work, you should really use total power since if your work takes less time you need fewer total servers (or fewer cloud CPU hours, etc) so the system power is also saved.
I think it’s more that a lower TDP might mean the compile takes 50% longer but I’m still multitasking and I might get 2h more out of a battery charge than when the cpu is spiking to max TDP
Yes, that's mentioned in the parent comment. The problem is that at slower frequencies also keep the core powered up for longer, which is often bad for power consumption. For many mobile devices, it's often much better to ramp up the processor to 100% and get the work done quickly, then rush to idle as quickly as possible.
This strategy is typically known as "race-to-sleep" or "race-to-idle". Just figured it was worth mentioning, as there's lots of additional information that can be found if you know what to search for.
I see what you’re saying but I believe there’s an issue at the silicon level where the gates literally use more power to do the same work at higher frequencies.
It's a well-known feature of CMOS gates that they consume almost all of their power at the moments of switching. AFAIK only recently has static leakage become substantial, necessitating power gating.
To add context: this is especially true for tasks that are likely to end in the device sleeping again. Two examples: user checking phone after hearing a notification sound or opening the laptop lid to check train departure time in the browser (then closing it again).
The faster the CPU deals with the task once the device is fully awake the shorter the time other power hungry parts of the system (like screen) need to be awake.
That's why slow phones, where the user needs to wait for their browser to finish loading the page will never be battery effective.
My view is that this works for CPU heavy tasks, but not for low-frequency repeated background tasks like browser window drawing, where if you speed up your CPU you just burn energy to get a higher framerate, something you generally don't care about on powersave.
So optimally you'd want to clock up for "burst tasks" and keep freq low for "per-frame tasks". But I don't know of a scheduler that does that, or even how it could do it. But if you assume most of your battery loss will be to frame tasks, powersave makes sense.
These kinds of things do get used in laptops–the keyword you're looking for is "race to idle", as the processor quickly clocks up and then rushes back to a lower-frequency state or even goes back to sleep. On the mobile side, I do know that Apple did work a couple years back to scale up to maximum clock rate very quickly to handle user-interactive tasks: https://www.anandtech.com/show/13392/the-iphone-xs-xs-max-re.... Then they'd ramp it back down to save on battery life.
I am not a hardware engineer, so I don't have actual stats on me, unfortunately. But the reasoning behind it makes sense: https://mjg59.livejournal.com/88608.html. Given that everyone is doing it, I am sure that there is data that shows that; I just don't have it :P
Well you can take the battery size (and screen times you get from those). iPhone batteries are tiny compared to android. Like seriously tiny that my 10Wh Powerbank can charge it 5 times with some to spare (I only really get 4 due to losses but still).
So yes comparing iPhones to anything else highly suggests that the tuning Apple did pays off. That being said: I’m not aware of a useful comparison. I’m not even sure how you would design something like that, ie what would you like to keep constant?
With the modern web there is no "rush back to idle". Browsers will burn your CPU until you turn off your browser, which in most cases is only when you turn your computer off.
Assuming you are using a reasonable browser with a reasonable set of websites open, a browser should not really burn unbounded CPU in the background. Tabs that do are generally throttled, allowing the scheduler to burst their work and then have the processor go back to sleep.
For what is worth, whatever adjustments are made on Linux (or at least Ubuntu) seem terrible compared to on Windows. If nothing else I can usually hear my fans working overtime even under minimal load on Linux compared to on Windows so I can see why people would look for more advanced tools.
“
…
Using tools like TLP will help in this situation with extending battery life (which is something I did for numerous years now), but it also might come with its own set of problems, like losing turbo boost.
With that said, I needed a simple tool which would automatically make "cpufreq" related changes, save battery like TLP, but let Linux kernel do most of the heavy lifting. That's how auto-cpufreq was born.
…
“
Would be great to have more real world benchmarks (in a climate chamber). To me any difference should show empirically. Does anyone have a good suggestion to "debug" performance/battery/thermal issue as a matter of trade-offs.
I feel that laptop performance is so subjective and very hard to track. Particularly thermal throttling on mobile Ryzen CPU makes my new Lenovo sometimes close to unusable. Particularly trying to do work while pandemic video conferencing seems to be more difficult than necessary...
You don't need a climate chamber; you can just measure energy consumption. Most modern battery management ICs should have a joule counter (or equivalent).
All mainstream CPUs and operating systems are dynamically adjusting frequency and other internal behavior to optimize power versus other factors. Some of these adjustment are done in hardware (i.e., intel_pstate aka "speed shift" aka HWP) which is both faster than software and can use internal metrics not available to software.
So you can't just say you're adjusting frequency dynamically to be optimal: something like that (or an attempt, at least) already happens. So what does this tool really do?
Are you talking about adjustments in hardware by drivers which can't even detect if my laptop is not connected to power source anymore and continue running on maximum frequency?
> Are you talking about adjustments in hardware by drivers which can't even detect if my laptop is not connected to power source anymore and continue running on maximum frequency?
I am talking about hardware power control in general. I wouldn't expect hardware power control itself to make different decisions based on plugged-in or not: that's a decision delegated to the user via the OS. HWP only implements low-level control based on the parameters set by something higher up.
I don't know if I'll watch the video, but you should make clear in your README what this tool actually does. Saying that it adjusts frequency dynamically isn't very useful. Telling people to disable `intel_pstate` without further comment is extremely suspect since then you're giving up HWP at an unknown cost.
If this simply adjusts the power governor when the laptop is plugged/unplugged, just say that!
Would you considered using intel_pstate=passive, and then use x86_energy_perf_policy/cpupower to turn the knobs on how to influence the governor? This'll let the CPU do its lower latency internal frequency changing. But of course, its not a one-size-fits-all approach for AMD/ARM.
On my Alienware AMD laptop, lm- sensors detects nothing. Do you think your program would help me on it? It doesn't support Linux but I'm running Ubuntu on it anyway. I have issues with screen brightness, fan speed, and battery life. Otherwise works great.
Best way to find out if it'll help you is to try it out! It has 2 modes, "monitor" which help you evaluate what it would do for you without making any actual changes.
If you like what it suggest you can run it in "live" mode, which will make the suggested changes. But after you stop "live" mode after reboot all settings will go back to defaults.
If you're happy with results then and want to run it in background all the time proceed with "install".
I tried it out. It doesn't get temps, as I expected. But it does switch down into power save mode on battery and switch back to performance on AC. Battery life has improved by over 50% from 4h to over 6h. Thanks for making this!
How do the the latest Intel and AMD CPU's compare in how they handle speed and power usage with regards to the main stand-out differences between the two?
I’d like something that would actually disable CPU cores temporarily besides fiddling with governors and clock speeds. I currently do that with a cpufreq GUI wrapper, but it isn’t automatic.
I tried taking 7 of my AMD Ryzen 5800HS’s 8 cores offline with `echo 0 | sudo tee /sys/devices/system/cpu/cpu{2..15}/online >/dev/null` and found it made no measurable difference to battery drain (as in, approximately less than 0.01W and certainly well less than 0.1W). I don’t know if I missed a step for actually turning the cores off, or whether you can’t actually turn them off, or whether the CPU is actually using way less power than I thought when idle (seems rather unlikely given my error bars). But if anyone did know a way of actually turning them off, I’d be very interested to see if I could get the whole laptop stably under 5W.
Oh, they go offline alright so that I can’t use them, but since that didn’t reduce power consumption, I’m not sure if the cores are actually switched off. Or if that’s even an option.
If you're comparing idle CPU power consumption, the cores are likely effectively "turned off" while idle anyway.
Offlining CPUs manually is still useful to limit what random software on your computer can do. There should still be difference between loading 1 CPU core to 100% and loading all 8 cores.
Though savings may be cancelled out a bit by CPU using higher boost frequencies when only one core is loaded. So you may need to disable boost too, if you want to save power by disabling CPUs for non-idle use case.
It would be easiest if I could say to the CPU: limit power use to this maximum. It's still doing it anyway to stay within TDP. Maybe there's some manual setting somewhere for that?
I had just hoped that actually off would be better than idling-off, a bit like how idling RAM consumes more power than off RAM.
For AMD’s CPUs/APUs, ryzenadj is a tool that does what you want. I use it when I want to constrain my power usage, switching it to a 5W TDP does better than just choosing the powersave governor.
I found that `sudo ryzenadj --stapm-limit 100 --fast-limit 100 --slow-limit 100`, telling it to aim for the unrealistically low limit of 100mW, reduces the clock speed below the standard 1.2GHz to 400MHz. Idling at 400MHz uses the same power as idling at 1.2GHz, but thrashing all cores at 400MHz definitely uses less power than thrashing all at 1.2GHz, though I can’t remember actual numbers (I did this a few months ago). Turning the machine into a single-thread 400MHz machine definitely slows things down!
I'm not an expert on this, and I don't know how the power-saving states for AMD processors work, but my understanding is that at least for modern Intel CPUs the deepest power-saving states pretty much turn the core off. [1]
Also, I'm not actually sure minimizing the clock frequency is going to maximize power savings. The voltage required for stable operation increases with the clock frequency, but the relationship is not linear. The top frequencies require proportionally higher voltage for the performance gains, so they are less power efficient. However, since the relationship is not linear, there may be a sweet spot between the minimum and the maximum with the lowest energy consumption per operation. [2] The power consumption per second will be at its lowest on the lowest clock frequency, but the power consumption for an entire computation might not be.
I’ve only ever seen powersave and performance being supported, on a wide range of laptops. With powersave being the default.
Powersave is noticeably slower on heavy workloads, and performance drains the battery on idle. So you have to keep toggling manually depending on your workload. Gonna try out this tool and hope it works.
Sad it can’t be built into the default governor. It’s not exactly easy to find these settings. There must be a lot of people out there with fancy hardware which they are unaware they are not utilizing to their full potential.
Actually, schedutil (the new ondemand) gets better perf/watt on modern Intel CPUs. Reality is more complex than "always crank up the CPU to the max" or "always turn it down all the way"; schedutil is optimized to do the right thing.
What's a straightforward way to clock down a CPU to a fixed rate?
I sometimes want to run benchmarks and I'd like my laptop to stick to one speed
I understand it's a bit problematic with the latest CPUs bc the gap between turbo and non turbo is so huge - and the CPU is in turbo a good chunk of the time (and your cache performance will be very different running at 1Ghz vs 4Ghz)
Downvotes, really? There is really no trick around thermals being the main performance limiting factor for the last 10 years, since CPUs started coming with hardware "turbo"
You're missing the point really. With a competent desktop cpu/mobo it's easy to peg the CPU clock at a certain frequency.
And with modern CPUs the power density is sufficently high that the die and heatspreader thermal resistance is enough to cause substantial temperature changes even with completely overspecced cooling.
Yeah but that's prolly not really a solution either (sidestepped the issue of modifying the cooler on a laptop). Bc you can't lock yourself to always be in turbo. So you can't get consistent performance while benchmarking
The problem is not understood by the prime majority:
As said above, the performance, and power consumption of modern CPUs is an "all, or nothing" choice.
Modern laptop CPUs are nothing, but well disguised desktop/server cores. Nobody designs designated mobile use cores, unless you are in ARM world.
In principle, they are unable to work in the "middle gear." CPU makers tried to make them to, but never managed to get a reasonable trade off. So you cannot run them reasonably at "half-performance"
Whats the overhead of this daemon running all the time?
It uses RAM which effectively increases power consumption because now something else is pushed out of the cache. It polls therefore waking the CPU every few seconds, even if perhaps nothing else is going on on the machine and the CPU would otherwise be idle.
I wonder if its benefits outweigh the disadvantages. Would be good to have numbers for a bunch of different hardware configs...
It's true it doesn't use much CPU in percentage terms... but wakeups are expensive.
When I'm reading a web page, ideally my CPU is halted, using barely any power. With the screen dim, I might be hoping for 20 hours battery life in that state.
To wake up, just to poll something, and go back to sleep again uses a lot of energy compared to doing nothing. Something polling a few times a second might reduce my 20 hours down to just 10.
TLP [1] covers this use case pretty well, although I confess I didn't expect this to still be an issue these days (until I bought my latest laptop and had to run TLP on Kubuntu 20.04 to ensure battery life on par with the factory specs, and TLP almost tripled it)
tuned does not automatically change the profile based on load, so it kind of has a different behavior. The point of auto-cpufreq is to give you power when needed and then switch back to powersave otherwise.
I’ve found http://tbswitcher.rugarciap.com/ that can turn of turbo boost on intel macs to be useful when on battery and compiling. Since 100% cpu usage will run at a much lower TDP and not kill my laptop battery as fast.
Reading the scripts it doesn't look like more than the standard Linux ricing script, which means that if you're using a well made distribution it will hurt you but if you're using a poorly made distribution it might help you.
In the recent years you really shouldn't have to worry about this anymore. You can check in powertop if your laptop CPU package idles for the most part in C8 or higher, and if it does great don't worry about it, and if it doesn't then look for the rogue software (like maybe some random scripts).
The CPU itself can change frequencies much faster on its own instead of the software based speedstep which programs like this controlled.
This eliminates the need for an on-battery or plugged-in performance mode because it changes frequencies so fast, you're no longer losing performance by waiting for the software to speed up the cpu. So you can keep it on all the time.
For these CPUs, all this is in the kernel and enabled by default.