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

[Adrian Chadd]

On 4 May 2014 22:18, Ian Smith <smithi at nimnet.asn.au> wrote:
> 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.

Yeah. Sorry, my mistake. One should just do the rc.conf change and reboot.

> 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.

Well, it's just convenient to set it to that. It's the same as Cmax.

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

Not sure. It's what's chosen when you use Cmax. :-)

> 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!

I've only had problems on an older Atom. That I'll bring with me to
bsdcan to finally show mav. Linux has had the same problem with this
particular Atom and timekeeping. ;(

>  > 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?

I'm not sure yet. Maybe make it userland and as part of the rc / power
scripts. That way Cmax gets turned into C1.



-a