proposal: set default lid state to S3, performance/economy Cx states to Cmax

[Ian Smith]

On Sun, 4 May 2014 17:25:50 -0700, Adrian Chadd wrote:
 > [snip]
 > 
 > The easy-to-run test is "sysctl dev.cpu.0.cx_lowest=Cmax" and then use stuff.

This doesn't work, on stable/9 at least, in that it only sets cpu.0 .. 
you need to set sysctl hw.acpi.cpu.cx_lowest - which rather surprised 
me, although that's what /etc/rc.d/power_profile has always set.  I 
guess it's only cpu.0.freq that still sets all CPUs in sync.

Further, rather than
 -economy_cx_lowest="HIGH" # Offline CPU idle state
 +economy_cx_lowest="Cmax" # Offline CPU idle state
you could use "LOW" which already sets it to "Cmax", though on 8.2:
 lowest_value="`(sysctl -n dev.cpu.0.cx_supported | \
        awk '{ print "C" split($0, a) }' -) 2> /dev/null`"

I'm not sure what the point of setting cx_lowest to C8 is on a machine 
where lowest cx_supported is C3, but it seems to do no harm on mine.

Where does C8 come from anyway?  Is that the lowest on any known 
hardware, or the lowest the ACPI spec supports?

root at x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C3
dev.cpu.0.cx_usage: 0.00% 0.79% 99.20% last 35us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_usage: 0.08% 1.59% 98.32% last 62us

root at x200:~ # sysctl dev.cpu.0.cx_lowest=Cmax
dev.cpu.0.cx_lowest: C3 -> C8
root at x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8				<<<<
dev.cpu.0.cx_usage: 0.00% 5.66% 94.33% last 73us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C3				<<<<
dev.cpu.1.cx_usage: 0.07% 1.91% 98.01% last 2us

root at x200:~ # sysctl dev.cpu.1.cx_lowest=C2
dev.cpu.1.cx_lowest: C3 -> C2
root at x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C3			<<<<
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8				<<<<
dev.cpu.0.cx_usage: 0.00% 0.19% 99.80% last 474us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C2				<<<<
dev.cpu.1.cx_usage: 3.47% 96.52% 0.00% last 1us

root at x200:~ # sysctl hw.acpi.cpu.cx_lowest=Cmax
hw.acpi.cpu.cx_lowest: C3 -> C8
root at x200:~ # sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C8
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_usage: 0.00% 3.05% 96.94% last 351us
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.cx_lowest: C8
dev.cpu.1.cx_usage: 0.00% 7.05% 92.94% last 2us

I've long run with C3 in AC power mode without issue, but don't know if 
that's true for all machines; all yours and mine are Thinkpads!

 > The problem is that we're not getting anywhere near enough exposure to
 > this kind of stuff because we don't have it on by default and we don't
 > have an active QA group with ridiculous amounts of hardware.
 > 
 > So, I'd like to flip it on and then start blacklisting devices that
 > actively don't work in halt states above C1. We're never going to
 > cross this bridge fully if we leave things at C1 out of fear.
 > 
 > I'm only suggesting we do this on -HEAD. If it's too scary then we can
 > always flip the default back to C1 for 11.0-RELEASE.

Yeah, I think this likely uncontroversial - unlike lid state S3 - and I 
don't recall hearing about machines that fail below C1 if lower states 
are shown as available.  As you say, this might shake these out.

But where would you put such a blacklist?  Someting like USB quirks?

cheers, Ian