That can't work on weberjn's FUTRO S720 as it has no battery, so devd cannot run /etc/rc.d/power_profile on notifies from ACPI ACAD, so sysctl hw.acpi.cpu.cx_lowest never changes, so nor sysctl dev.cpu.{0,1}.cx_lowest - however these may be set in /etc/sysctl.conf.
what has a battery to do with the C-states? Those entries set the "hw.acpi.cpu.cx_lowest" as well as all "dev.cpu.N.cx_lowest" to the lowest state supported by the OS (C8):
Code:
# sysctl -a | grep cx_lowest
hw.acpi.cpu.cx_lowest: C8
dev.cpu.11.cx_lowest: C8
dev.cpu.9.cx_lowest: C8
dev.cpu.7.cx_lowest: C8
dev.cpu.5.cx_lowest: C8
dev.cpu.3.cx_lowest: C8
dev.cpu.1.cx_lowest: C8
dev.cpu.10.cx_lowest: C8
dev.cpu.8.cx_lowest: C8
dev.cpu.6.cx_lowest: C8
dev.cpu.4.cx_lowest: C8
dev.cpu.2.cx_lowest: C8
dev.cpu.0.cx_lowest: C8
# sysctl -a | grep cx_supp
dev.cpu.11.cx_supported: C1/1/1 C2/2/253 C3/3/1048
dev.cpu.9.cx_supported: C1/1/1 C2/2/253 C3/3/1048
dev.cpu.7.cx_supported: C1/1/1 C2/2/253 C3/3/1048
dev.cpu.5.cx_supported: C1/1/1 C2/2/253 C3/3/1048
dev.cpu.3.cx_supported: C1/1/1 C2/2/253 C3/3/1048
dev.cpu.1.cx_supported: C1/1/1 C2/2/253 C3/3/1048
dev.cpu.10.cx_supported: C1/1/1 C2/2/253 C3/3/1048
dev.cpu.8.cx_supported: C1/1/1 C2/2/253 C3/3/1048
dev.cpu.6.cx_supported: C1/1/1 C2/2/253 C3/3/1048
dev.cpu.4.cx_supported: C1/1/1 C2/2/253 C3/3/1048
dev.cpu.2.cx_supported: C1/1/1 C2/2/253 C3/3/1048
dev.cpu.0.cx_supported: C1/1/1 C2/2/253 C3/3/1048
# grep cx_low /etc/rc.conf
performance_cx_lowest="Cmax"
economy_cx_lowest="Cmax"
This is taken from my work desktop I'm currently sitting at. (no battery)
from
rc.conf(5):
Code:
performance_cx_lowest
(str) CPU idle state to use while on AC power. The string
“LOW” indicates that acpi(4) should use the lowest power
state available while “HIGH” indicates that the lowest
latency state (less power savings) should be used.
[...]
economy_cx_lowest
(str) CPU idle state to use when off AC power. The string
“LOW” indicates that acpi(4) should use the lowest power
state available while “HIGH” indicates that the lowest
latency state (less power savings) should be used.
So on normal systems "performance_cx_lowest" should be sufficient and "economy_cx_lowest" is only necessary for systems that actually *can* be off AC power (i.e. have a battery).
I have both lines in my rc.conf template, so it ends up on all systems I set up and does no harm.
Which systems? I can't see how that could be possible, when changing CPU speed doesn't affect C-states?
The cx_usage statistics were slightly shifted towards the higher (i.e. numerical lower) states on average when I ran powerdxx. However; power readings from IPMI didn't show any difference, so the actual impact might be lost in normal fluctuations. But as reducing clock rates has zero additional impact on power consumption with enabled (and working) C-states, yet sometims significant impact on performance, especially because powerdxx often fails to set the clock rates to turbo-boost frequency, I don't use it anywhere.
This was tested on 4 (2 pairs of identical) servers with dual Xeon E5 v4 (Broadwell), where I set Cmax and then enabled powerd(xx) only on one of each pair. Power readings were gathered via zabbix by running a script that basically executes
ipmitool dcmi power reading.
Even C-state C8 doesn't 'shut down a core', and reducing clock speed according to load (esp. no load) makes a large difference in power use on any processor I've seen.
Describes the various power management sleep states in mobile laptop systems.
www.intel.com
C2 - Stop Clock: Core and bus clocks are off. The processor maintains all software-visible state, but can take longer to wake up.
C3 - Deep Sleep: Clock generator is off. The processor does not need to keep its cache coherent, but maintains other states. Some processors have variations of the C3 state (Deep Sleep, Deeper Sleep) that differ by how long it takes to wake the processor.
C4 - Deeper Sleep: Reduced VCC
Beginning with C2 some or all (C3) clock generators are off - this means that changing the clock rates doesn't make any sense or difference any more. At C4 and higher the VCC is reduced, at C6 this explicitly includes 0V, which is basically "shutting down" the core.
Well I've only used older Intel CPUs in recent decades, which ones do you refer to?
I have various systems at hand, starting from haswell/broadwell, skylake, some jasper lake up to Tiger and Alder Lake. (no AMD though - last one I used was an Athlon 64)
On *all* those systems (servers, appliances/routers, desktops, laptop...) I use those cx_lowest settings in /etc/rc.conf and they successfully set the cx_lowest sysctls to "C8".
