Via TLP on Linux, I've been capping my laptop's CPU (i7-8665U) to 800Mhz whenever I'm on battery. 800Mhz on a relatively modern CPU is quite remarkably fast and sufficient for most things.
Out of curiosity I've got CPU Frequency being polled periodically and updated in my taskbar, and the CPU spends a remarkable amount of time bouncing between ~600Mhz and ~800Mhz, because even when actively working, it's quite quiescent. Obviously compiling, running test suite, browsing etc. etc. will cause it to jump up to full speed (4.1Ghz with turbo, or there abouts).
One of the things I've found myself doing is paying a bit more attention to _what_ is consuming CPU resources when that frequency goes up. For example, I noticed that Zoom will randomly consume a couple of % of a CPU for about 20-30 seconds periodically. I know it also maintains some kind of notification hook to Zoom infrastructure. I don't need that persistent feature, so now I have a lightweight bash script that looks to see if I'm in a Webinar or Meeting, and if not, nukes zoom. The advantages are probably minimal, at best, but it took my fancy for whatever reason :)
> Via TLP on Linux, I've been capping my laptop's CPU (i7-8665U) to 800Mhz whenever I'm on battery.
in most cases, on modern hardware, limiting the frequency significantly below its nominal maximum will reduce battery life. for a fixed amount of work (e.g. parsing an HTML document), it is more efficient to complete the task as quickly as possible then return to a low-power state. the picture gets somewhat murkier when considering increased voltage requirements at higher clock speeds and certain fixed-wakeup workloads, but the majority of scheduler tuning for battery-powered devices over the past decade has been towards going to sleep as quickly as possible, even if that requires a high peak frequency.
Out of curiosity I've got CPU Frequency being polled periodically and updated in my taskbar, and the CPU spends a remarkable amount of time bouncing between ~600Mhz and ~800Mhz, because even when actively working, it's quite quiescent. Obviously compiling, running test suite, browsing etc. etc. will cause it to jump up to full speed (4.1Ghz with turbo, or there abouts).
One of the things I've found myself doing is paying a bit more attention to _what_ is consuming CPU resources when that frequency goes up. For example, I noticed that Zoom will randomly consume a couple of % of a CPU for about 20-30 seconds periodically. I know it also maintains some kind of notification hook to Zoom infrastructure. I don't need that persistent feature, so now I have a lightweight bash script that looks to see if I'm in a Webinar or Meeting, and if not, nukes zoom. The advantages are probably minimal, at best, but it took my fancy for whatever reason :)