Re: New hw.perfpolicy behavior
On Nov 10 00:21:59, h...@stare.cz wrote: > On Nov 02 12:30:56, dera...@openbsd.org wrote: > > Paul de Weerd 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? > > > > 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 > > > > 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. > > Measuring on this PC running current/amd64 (dmesg below), > with a Sep 26 snapshot and the latest snapshot. > > As a naive test, I am measuring the power consumption > of compiling the kernel (is that too small?). > > The numbers are mostly the same on both of these systems, > with each of apmd with apm -A, -H, -L respectively, > or without running apmd at all. For comparison, the numbers are not the same on a Thinkpad T400 (dmesg below) running on battery. acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS apm -A (hw.setperf=0 hw.perfpolicy=auto) took 14m23.20s to compile the kernel, consuming 28.93 - 21.28 = 7.65 Wh (by hw.sensors.acpibat0.watthour3) apm -H (hw.setperf=100 hw.perfpolicy=manual hw.cpuspeed=2267) took 14m27.63s, consuming 19.25 - 11.04 = 8.21 Wh apm -L (hw.setperf=0 hw.perfpolicy=manual hw.cpuspeed=800) took 37m18.40s, consuming 22.25 - 10.02 = 12.23 Wh So at last here, apm -A is better than apm -H, but apm -L is clearly the worst. Jan OpenBSD 7.0-current (GENERIC.MP) #104: Thu Nov 18 09:10:05 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8461684736 (8069MB) avail mem = 8189267968 (7809MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012 bios0: LENOVO 64741EG acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.33 MHz, 06-17-06 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 266MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.01 MHz, 06-17-06 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0xfed4/0x5000, device 0x10208086 rev 0x6 acpibat0 at acpi0: BAT0 model "92P1137" serial57 type LION oem "SANYO" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0: version 1.0 "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(100@57
Re: New hw.perfpolicy behavior
Nicola Dell'Uomo wrote: > Hi, > > I tested my laptop using different -CURRENT releases (#67, #71, #76) and the > problem persists. > First of all I disabled apmd as Theo suggested and my laptop did not auto > suspended anymore. > This is the output of systat sens -1 when my system fails to read battery > status (with last output from a working setup, just for comparison): > > > acpibat0.volt015.40 V DC voltage > acpibat0.volt1 0.00 V DC unknown current voltage > acpibat0.power0 0.00 W unknown rate > acpibat0.watthour0 51.99 Wh last full capacity > acpibat0.watthour1 2.60 Wh warning capacity > acpibat0.watthour2 0.20 Wh low capacity > acpibat0.watthour3 0.00 Wh unknown remaining capacity > acpibat0.watthour4 51.00 Wh design capacity > acpibat0.raw0 1 raw unknown battery unknown > acpibat0.raw1335 raw discharge cycles I don't think this is a software problem.
Re: New hw.perfpolicy behavior
On Tue, Nov 9, 2021 at 3:29 PM Jan Stary wrote: > On Nov 10 00:21:59, h...@stare.cz wrote: > > Regarding C states, this machine has > > > > acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), > C1(1000@1 mwait.1), PSS > > > > I suppose the cpu supports C1, C2, C3, but can someone please kindly > > explain (or point to an explanation of) what the whole line says? > > For comparison, my Thinkpad T400 has > acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), > C1(1000@1 mwait.1), PSS > What does the ! mean? > This is generated by sys/dev/acpi/acpicpu.c:acpicpu_print_one_cst() and at this point should either be suppressed by default or documented in the manpage; I'm not sure which. To enumerate it from right to left: !C3(100@57 mwait.3@0x30) ^ ^ ^ ^ ^ ^ ^ | ||| | | | | ||| | | \-- 'hints' passed to the actual MWAIT instruction, or address for 'io' method | ||| | \-- fixed-function level bit flags: 1="HW coordinated" 2="bus-master avoidance required" | ||| | OR '!' if this is a faked-up fallback to the pre-CST C1-via-HALT (bios is broken) | ||| \-- sleep method, one of mwait, io, or halt | ||\-- advertised latency when exiting the state | |\-- advertised power-consumption | \-- the C state, duh \-- '!' to indicate this state is disabled because the CPU's LAPIC stops in C2 or deeper (no ARAT)
Re: New hw.perfpolicy behavior
On Nov 10 00:21:59, h...@stare.cz wrote: > Regarding C states, this machine has > > acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), > C1(1000@1 mwait.1), PSS > > I suppose the cpu supports C1, C2, C3, but can someone please kindly > explain (or point to an explanation of) what the whole line says? For comparison, my Thinkpad T400 has acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS What does the ! mean?
Re: New hw.perfpolicy behavior
On Nov 02 12:30:56, dera...@openbsd.org wrote: > Paul de Weerd 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? > > 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 > > 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. Measuring on this PC running current/amd64 (dmesg below), with a Sep 26 snapshot and the latest snapshot. As a naive test, I am measuring the power consumption of compiling the kernel (is that too small?). The numbers are mostly the same on both of these systems, with each of apmd with apm -A, -H, -L respectively, or without running apmd at all. Namely, it takes about 04:30 to make, and it consumes about 0.007 kWh. Then again, doing nothing for 04:30 consumes about 0.004. (Are these too small to be a measurement?) Regarding C states, this machine has acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS I suppose the cpu supports C1, C2, C3, but can someone please kindly explain (or point to an explanation of) what the whole line says? Thank you Jan OpenBSD 7.0-current (GENERIC.MP) #85: Tue Nov 9 13:24:56 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17009606656 (16221MB) avail mem = 16478068736 (15714MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.74 MHz, 06-2a-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.30 MHz, 06-2a-07 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.30 MHz, 06-2a-07 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3392.30 MHz, 06-2a-07 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 2
Re: New hw.perfpolicy behavior
Hmm. Stop using apmd, and run systat sens 1 And watch to see what happens to the various sensors. This will show you everything. Nicola Dell'Uomo wrote: > Battery self test is okay and my laptop has just 1 year of life (X1 carbon > 8th gen). > The problem replicated just now after a system reboot (I needed to reboot in > order to execute self diagnose), and my laptop don't restart if I don't plug > ac power in (a couple of seconds suffice: then battery resumes at its > previous value). > Any advice on how to verify this is just my battery problem? > Consider this laptop has just OpenBSD installed. > > ‐‐‐ Original Message ‐‐‐ > > Il mercoledì 3 novembre 2021 4:21 PM, Theo de Raadt ha > scritto: > > > It looks like your battery is failing. > > > > Nicola Dell'Uomo ndellu...@protonmail.com wrote: > > > > > I've been experiencing odd power management behavior since some days: my > > > laptop goes to suspend and I didn't know why. > > > > > > Today I looked at /var/messages and I found this out: > > > > > > [snip] > > > > > > Nov 3 15:04:20 puffy apmd: system resumed from sleep > > > > > > Nov 3 15:04:20 puffy apmd: battery status: high. external power status: > > > not connected. estimated battery life 60% (294 minutes) > > > > > > Nov 3 15:04:25 puffy apmd: battery status: high. external power status: > > > not connected. estimated battery life 100% > > > > > > Nov 3 15:16:50 puffy apmd: battery status: high. external power status: > > > not connected. estimated battery life 56% (267 minutes) > > > > > > Nov 3 15:24:18 puffy apmd: battery status: CRITICAL. external power > > > status: not connected. estimated battery life 0% > > > > > > Nov 3 15:24:18 puffy apmd: estimated battery life 0% below configured > > > limit 10% > > > > > > Nov 3 15:24:18 puffy apmd: system suspending > > > > > > Nov 3 15:24:18 puffy apmd: battery status: CRITICAL. external power > > > status: not connected. estimated battery life 0% > > > > > > Nov 3 15:24:19 puffy apmd: battery status: high. external power status: > > > not connected. estimated battery life 100% > > > > > > Nov 3 15:24:20 puffy /bsd: video0 detached > > > > > > Nov 3 15:24:20 puffy /bsd: uvideo0 detached > > > > > > Nov 3 15:24:20 puffy /bsd: video1 detached > > > > > > Nov 3 15:24:20 puffy /bsd: uvideo1 detached > > > > > > Nov 3 15:24:20 puffy /bsd: ugen0 detached > > > > > > Nov 3 15:27:52 puffy syslogd[9001]: start > > > > > > [snip] > > > > > > The same happened just now (while I was writing) and I was able to exit > > > from suspend only by plugging the power cable in, closing the lid, and > > > opening it again. > > > > > > Is this the correct thread or do you want me to file a bug via sendbug to > > > b...@openbsd.org? > > > > > > I have apmd_flags= "-A -z 10" in my rc.conf.local
Re: New hw.perfpolicy behavior
It looks like your battery is failing. Nicola Dell'Uomo wrote: > I've been experiencing odd power management behavior since some days: my > laptop goes to suspend and I didn't know why. > Today I looked at /var/messages and I found this out: > [snip] > Nov 3 15:04:20 puffy apmd: system resumed from sleep > Nov 3 15:04:20 puffy apmd: battery status: high. external power status: not > connected. estimated battery life 60% (294 minutes) > Nov 3 15:04:25 puffy apmd: battery status: high. external power status: not > connected. estimated battery life 100% > Nov 3 15:16:50 puffy apmd: battery status: high. external power status: not > connected. estimated battery life 56% (267 minutes) > Nov 3 15:24:18 puffy apmd: battery status: CRITICAL. external power status: > not connected. estimated battery life 0% > Nov 3 15:24:18 puffy apmd: estimated battery life 0% below configured limit > 10% > Nov 3 15:24:18 puffy apmd: system suspending > Nov 3 15:24:18 puffy apmd: battery status: CRITICAL. external power status: > not connected. estimated battery life 0% > Nov 3 15:24:19 puffy apmd: battery status: high. external power status: not > connected. estimated battery life 100% > Nov 3 15:24:20 puffy /bsd: video0 detached > Nov 3 15:24:20 puffy /bsd: uvideo0 detached > Nov 3 15:24:20 puffy /bsd: video1 detached > Nov 3 15:24:20 puffy /bsd: uvideo1 detached > Nov 3 15:24:20 puffy /bsd: ugen0 detached > Nov 3 15:27:52 puffy syslogd[9001]: start > [snip] > The same happened just now (while I was writing) and I was able to exit from > suspend only by plugging the power cable in, closing the lid, and opening it > again. > Is this the correct thread or do you want me to file a bug via sendbug to > b...@openbsd.org? > I have apmd_flags= "-A -z 10" in my rc.conf.local >
Re: New hw.perfpolicy behavior
On Wed, Nov 03, 2021 at 11:55:41AM +, Stuart Henderson wrote: > On 2021/11/03 05:47, Crystal Kolipe wrote: > > > 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 > > > > > > 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. > > > > This high frequcency cycling causes detectable (*) RF noise. In the vast > > majority of cases this shouldn't be an issue, but it seems worth noting > > just in case we start seeing bug reports of humming on speakers once > > this change sees it's way into the next release and more people are > > exposed to it. > > using mwait is a years-old change It certainly is. I'm not sure what if anything that has to do with the current discussion. When the CPU is manually throttled to a lower speed, which is effectively what the OP was doing, logically it will be placed into the lower C states less often if at all, as there is less idle time. THIS changes the RF noise profile of the equipment, as does many other things. Have you measured the typical RF of any system with the OP's configuration before and after the commit he mentioned? I see a detectable but insignificant to me difference.
Re: New hw.perfpolicy behavior
On Tue, Nov 02, 2021 at 12:26:15PM -0600, Theo de Raadt wrote: > 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, until an interrupt happens. And thus, save > power. That is how modern cpus work. I've been running "apmd -A" on all the incarnations of my home server since as long as I can remember (15+ years). If I understand the above correctly, manipulating hw.setperf is in general not the best way to save power on modern CPUs, which would mean running "apmd -A" is not useful anymore on such systems. Is my understanding correct? -- Jurjen Oskam
Re: New hw.perfpolicy behavior
On 2021/11/03 05:47, Crystal Kolipe wrote: > > 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 > > > > 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. > > This high frequcency cycling causes detectable (*) RF noise. In the vast > majority of cases this shouldn't be an issue, but it seems worth noting > just in case we start seeing bug reports of humming on speakers once > this change sees it's way into the next release and more people are > exposed to it. using mwait is a years-old change
Re: New hw.perfpolicy behavior
On Tue, Nov 02, 2021 at 12:30:56PM -0600, Theo de Raadt wrote: > Paul de Weerd 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? > > 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 > > 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. This high frequcency cycling causes detectable (*) RF noise. In the vast majority of cases this shouldn't be an issue, but it seems worth noting just in case we start seeing bug reports of humming on speakers once this change sees it's way into the next release and more people are exposed to it. The change in noise profile can be tested and measured in a crude way using a simple loop of unsheilded wire connected to some small speakers. (*) Detectable when deliberately looked for. In a correctly shielded system I haven't observed and don't expect any negative effects. In terms of power consumption, I see no significant measurable change on two systems tested here.
Re: New hw.perfpolicy behavior
On Wed, 3 Nov 2021, Stuart Henderson wrote: > > See also https://en.wikichip.org/wiki/race-to-sleep - it's generally > > more energy efficient to run the CPU at full speed so it can finish its > > work faster and get back to a low-power state sooner > > So there's not really any point in doing this scaling on laptops either > then, and it could be counterproductive? Would it actually be better for > the decision to be "has mwait or an alternative mechanism on other arches" > and only if that's absent consider whether it has ac power? It really depends on the workload. If you're compiling something then going full tilt and then sleeping would probably be better, if you've got a web browser running JS in the background then maybe cpufreq scaling will win... -d
Re: New hw.perfpolicy behavior
On 2021/11/03 16:46, Damien Miller wrote: > On Tue, 2 Nov 2021, Theo de Raadt wrote: > > > Paul de Weerd 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? > > > > 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 > > > > 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. > > See also https://en.wikichip.org/wiki/race-to-sleep - it's generally > more energy efficient to run the CPU at full speed so it can finish its > work faster and get back to a low-power state sooner So there's not really any point in doing this scaling on laptops either then, and it could be counterproductive? Would it actually be better for the decision to be "has mwait or an alternative mechanism on other arches" and only if that's absent consider whether it has ac power?
Re: New hw.perfpolicy behavior
On Tue, Nov 02, 2021 at 12:30:56PM -0600, Theo de Raadt wrote:
| Paul de Weerd 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/
Re: New hw.perfpolicy behavior
On Tue, 2 Nov 2021, Theo de Raadt wrote: > Paul de Weerd 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? > > 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 > > 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. See also https://en.wikichip.org/wiki/race-to-sleep - it's generally more energy efficient to run the CPU at full speed so it can finish its work faster and get back to a low-power state sooner
Re: New hw.perfpolicy behavior
Solene Rapenne wrote:
> On mardi 2 novembre 2021 19:19:03 CET, Paul de Weerd 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.
> >
> > [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?
> >
> > Paul
> >
>
> Hello,
>
> I noticed a 1 watt or so increase on idle on a T470
> which is perfectly acceptable for me given the
> responsiveness boost that comes with this change.
>
How dare you
Re: New hw.perfpolicy behavior
> Date: Tue, 2 Nov 2021 19:19:03 +0100
> From: Paul de Weerd
>
> 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.
>
> [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?
Did you measure the power consumption?
Re: New hw.perfpolicy behavior
Paul de Weerd 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?
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
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.
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 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.
Re: New hw.perfpolicy behavior
Paul de Weerd 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?
You must measure, to make the claim.
The OptiPlex 9020 is a modern i7, approximately 4785T generation, and
these contain C states:
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, until an interrupt happens. And thus, save
power. That is how modern cpus work.
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.
New hw.perfpolicy behavior
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.
[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?
Paul
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
