[OmniOS-discuss] [discuss] illumos power management

Paul B. Henson henson at acm.org
Thu Nov 14 04:00:29 UTC 2013


On 11/13/2013 11:24 AM, Garrett D'Amore wrote:
> CPU power management is unlikely to do much for you.  Its better to rely
> on C-states to save power on modern systems.

I'm not sure how to interpret that; the power.conf man page says that if 
cpu_deep_idle is enabled "On X86 systems this can translate to the use 
of ACPI C-States beyond C1", so it seems illumos is already using C 
states for CPU power management?

> Frankly, very very few components on typical illumos based
> systems even support power management apart from the disk subsystem.

Probably only disks and CPU I would think, although it would be nice to 
be able to list out what the system thinks it could manage. I definitely 
don't want to spin down the disks, but I wouldn't mind saving a few 
watts here and there on the CPU. So maybe something like:

autopm                  disable
autoS3                  disable
cpupm                   enable
cpu_deep_idle           enable

> The display subsystem typically uses its own power management which
> doesn't participate with the rest of illumos' power management
> framework, IIRC.)

Unlike good old SPARC boxes, my x86 "headless" server has a graphics 
adapter in it. As I'm using a serial console, all it ever displays after 
boot is a blank screen, can't imagine it takes much power...

> want, except to indicate "policy"  -- modern devices (disk drives
> notwithstanding) can generally raise and lower power so quickly that its
> best to just let the drivers do their own power management explicitly,
> with only a few monitoring and policy hooks.  This would lead to a
> vastly simpler power framework, which would probably be more likely to
> be taken up driver authors than the current mess.

I think that's where Linux is heading, the new Intel P-state driver for 
CPU power management doesn't really have any options, just turn it on 
and let it do its thing... They determined the previous ACPI driver 
actually ended up using more power by waking up the CPU to decide 
whether or not it should decrease the frequency than just letting the 
CPU deal with it itself internally.

Thanks…


More information about the OmniOS-discuss mailing list