On Tue, Nov 02, 2021 at 12:30:56PM -0600, Theo de Raadt wrote: | Paul de Weerd <we...@weirdnet.nl> 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/