The processor power states, or C-states, are low-power modes that can be used when the CPU is idle. The idea is not new: already in the 80486 processor a specific instruction (HLT) was used for this purpose. This was later accompanied by a pair of other instructions (MONITOR, MWAIT). By default,
NetBSD may use either one; see the
machdep.idle-mechanism sysctl(8) variable. ACPI provides the latest amendment.
The following C-states are typically available. Additional processor or vendor specific states (C4, ..., Cn) are handled internally by
acpicpu.
C0
This is the normal state of a processor; the CPU is busy executing instructions.
C1
This is the state that is typically reached via the mentioned x86 instructions. On a typical processor, C1 turns off the main internal CPU clock, leaving APIC running at full speed. The CPU is free to temporarily leave the state to deal with important requests.
C2
The main difference between C1 and C2 lies in the internal hardware entry method of the processor. While less power is expected to be consumed than in C1, the bus interface unit is still running. But depending on the processor, the local APIC timer may be stopped. Like with C1, entering and exiting the state are expected to be fast operations.
C3
This is the deepest conventional state. Parts of the CPU are actively powered down. The internal CPU clock is stopped. The local APIC timer is stopped. Depending on the processor, additional timers such as TSC (time stamp counter) may be stopped. Processor caches may be flushed. Entry and exit latencies are expected to be high; the CPU can no longer “quickly” respond to bus activity or other interruptions.
Each state has a latency associated with entry and exit. The higher the state, the lower the power consumption, and the higher the potential performance costs.
The
acpicpu driver tries to balance the latency constraints when choosing the appropriate state. One of the checks involves bus master activity; if such activity is detected, a lower state is used. It is known that particularly
usb(4) may cause high activity even when not in use. If maximum power savings are desirable, it may be necessary to use a custom kernel without USB support. And generally: to save power with C-states, one should avoid polling, both in userland and in the kernel.