On Tue, Nov 02, 2021 at 12:30:56PM -0600, Theo de Raadt wrote:
| Paul de Weerd <[email protected]> wrote:
|
| > A recent commit by Theo changed the hw.perfpolicy behavior to always
| > run at full speed when AC power is on. This means that my workstation
| > (and servers, once I upgrade them) now consumes significantly more
| > power, even though they usually idle.
|
| Did you measure how much more power?
Admittedly, I didn't. I have a colocated server that has had its
power usage measured for years (I'm charged per kWh, so each monthly
invoice has the usage for the month prior), and I recalled a
significant drop in usage from years ago. I thought this was back
when hw.perfpolicy=auto was introduced in 2014, but I was mistaken: it
was the introduction of support for C-states one year later that gave
that result: my machine went from ~30 kWh per month to ~20 kWh per
month. (note that that was an older generation CPU: cpu0: Intel(R)
Xeon(R) CPU E31260L @ 2.40GHz, 2394.97 MHz, 06-2a-07).
Those were the significant savings I recalled. Apologies for the
false claim there, I had these two mixed up in my head.
| You must measure, to make such a claim.
|
| Your OptiPlex 9020 is probably a modern i5/i7, which probably contains
| C states similar to this:
|
| acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
You're right, of course:
cpu0: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3691.93 MHz, 06-3c-03
...
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
| Which means when the idle loop calls the "mwait" instruction, the cpu
| will 'instantly' slow down to a lower clock and make other power use
| reductions, until an interrupt happens and requires labour again.
|
| Most modern cpus dynamically downscale in such way, which mostly
| obliterates the requirement to manually control things, or even handle
| it in a slow-paced data-weak way in the scheduler.
Thank you for that explanation, that makes a lot of sense.
| So you must back your claim up with power measurements.
|
| > [weerd@pom] $ sysctl hw.{vendor,product,perfpolicy,setperf,cpuspeed}
| > hw.vendor=Dell Inc.
| > hw.product=OptiPlex 9020
| > hw.perfpolicy=auto
| > hw.setperf=100
| > hw.cpuspeed=3401
| >
| > If I'd want to use the old behavior on "non laptop" systems, what
| > would be the best approach to try to achieve that? I mean, I can
| > revert the commit, but then I'm stuck with a frankenstein system.
| >
| > Would another "economy" perfpolicy be better, or would it make more
| > sense to try to divine the type of system and adjust accordingly?
|
| From false premises straight to conclusions that we (OpenBSD) must do
| something. Come on.
I wanted to look into this myself. At least with the current code,
the 'auto' perfpolicy doesn't do much on "non laptop" systems: they're
always on AC, so the processor never scales back and the effect is
then the same as the 'high' setting. I suppose I'll change those
systems back to run with 'high' and let the processor handle things
itself, from what I've learned now it seems that this knob is a bit
superfluous on my systems and I should stop tweaking it.
| I purchased every one of my machines to get the maximum performance out
| of them when they are doing work, and I expect everyone else is in the
| same group. Otherwise they would have saved money by buying slower
| machines. Lucky for us that modern cpus do this automatically.
Right, I thought that was what 'auto' did: scale up the frequency when
the machine was doing work so it would have it done faster and then
scale down again, saving power / reducing heat in the process. I
understand now that this happens anyway.
Thanks again for the cluestick.
Paul
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
