More Power Management Updates Queue Up For Linux 4.6

[phoronix]

Phoronix: More Power Management Updates Queue Up For Linux 4.6

Last week was the big ACPI and power management updates for Linux 4.6 that included a redesign of CPUFreq and P-State to support callbacks invoked by the kernel's scheduler. A few more feature changes have now been queued up for pulling of the ACPI+PM work for Linux 4.6...

http://www.phoronix.com/scan.php?page=news_item&px=More-ACPI-PM-For-Linux-4.6

[milkylainen]

From a purist point of view I hate how much knowledge software has to have on hardware to "tune" it.
Power management of different sorts are the worst.
ACPI, CPUFreq, Voltage scaling, PCI-E ASPM, USB power saving, suspend states, hardware monitoring, C-states, cpu-boost, idle instructions etc etc.
I usually only have issues with the bucketloads of crap code they keep throwing at the problem.
Personally, I'd do away with all this with hardware. I don't think cpu-freq scaling or voltage scaling etc should be visible from software at all.
It's a hardware design issue to optimize power consumption.
It was a while ago, but from 4.6, my desktop kernel builds will have 0 power saving features compiled. Don't want to care. It's a bullshit problem to have in software.

[mudig]

It was a while ago, but from 4.6, my desktop kernel builds will have 0 power saving features compiled. Don't want to care. It's a bullshit problem to have in software.

Uh, have fun listening to your fans? I suggest you stop caring by leaving the power saving features alone

[milkylainen]

Uh, have fun listening to your fans? I suggest you stop caring by leaving the power saving features alone

Don't worry. I have earplugs.
Seriously though. You totally overestimate how much software can do compared to well tuned hardware.
I have already tried. My hardware hardly consumes any more power by disabling all this crap.
Adding this stuff in software only increases execution time where the hardware cannot sleep.
It is totally contraproductive compared to hardware that is doing it's job properly.
A lot of test have far lower power consumption by letting the CPU do it's job as quickly as possible and then returning to sleep without the intervention of frequency scalers etc.
The same should go for voltage scaling, ASPM, etc. There should be no need for software to fiddle with PM.

[gilboa]

From a purist point of view I hate how much knowledge software has to have on hardware to "tune" it.
Power management of different sorts are the worst.
ACPI, CPUFreq, Voltage scaling, PCI-E ASPM, USB power saving, suspend states, hardware monitoring, C-states, cpu-boost, idle instructions etc etc.
I usually only have issues with the bucketloads of crap code they keep throwing at the problem.
Personally, I'd do away with all this with hardware. I don't think cpu-freq scaling or voltage scaling etc should be visible from software at all.
It's a hardware design issue to optimize power consumption.
It was a while ago, but from 4.6, my desktop kernel builds will have 0 power saving features compiled. Don't want to care. It's a bullshit problem to have in software.

For *your* minute use case, power management is a non-issue.
For the vast majority of the 1+ billion Linux users out there, software power management is the *only* solution.

The same should go for voltage scaling, ASPM, etc. There should be no need for software to fiddle with PM.

Sorry for being blunt, but this statement is completely clueless.
E.G. In the current HP DL and ML generation 9 servers HP integrated "smart" firmware that helps HP reduce the power usage by a considerable amount.
However, this firmware only supports Windows and RHEL/SUSE and has severe issues under non-RHEL/SUSE kernels (it fails to detect the actual CPU load, dropping cores to C6 even if they are under 50-80% load)

To put this in perspective, we saw a 10-20% performance decrease (compared to alternatives) when running dual Xeon V3 CPUs DL160/380/Apollo 4200/4500 machine under Linux 4.3/4.4 and 70-90% (!!!!) performance drop when running quad Xeon V3 CPUs DL560 under the same kernel. (Needless to say that everything worked out of the box under RHEL 7.2)
After a lot of trial and error, we managed to create a OS-only (!) power management profile for each machine (based around Intel P-state w/ performance governor) and the performance of *all* our HP servers went through the roof (The DL560G9 managed to out perform a comparable machine by 15-20%)

Now, HP is not alone, we've seen comparable issues when using "unsupported OSs" on IBM (Now Lenovo) and Dell servers.
Firmware based PM is always PITA as you are locked to the HW manufacturer supported-OS list and you cannot circumvent firmware PM issues.

- Gilboa