Date: Mon, 5 May 2014 15:18:03 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Adrian Chadd <adrian@freebsd.org> Cc: Kevin Oberman <rkoberman@gmail.com>, "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org>, Rui Paulo <rpaulo@felyko.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax Message-ID: <20140505135809.Y11699@sola.nimnet.asn.au> In-Reply-To: <CAJ-Vmo=aWmrxYPq9znwwi3C4wqf%2B_Q0DE3eLjmNMuHXVDnLHfA@mail.gmail.com> References: <CAJ-Vmo=mUtpjgVwNHg8af05vCxVchZdsaekR9_Wf-pOfFjnABQ@mail.gmail.com> <FCE7DE37-81D4-4859-98DF-89E606B29CAC@felyko.com> <alpine.BSF.2.00.1405041641290.9118@wonkity.com> <CAJ-Vmo=aWmrxYPq9znwwi3C4wqf%2B_Q0DE3eLjmNMuHXVDnLHfA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@x200:~ # sysctl dev.cpu.0.cx_lowest=Cmax
dev.cpu.0.cx_lowest: C3 -> C8
root@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@x200:~ # sysctl dev.cpu.1.cx_lowest=C2
dev.cpu.1.cx_lowest: C3 -> C2
root@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@x200:~ # sysctl hw.acpi.cpu.cx_lowest=Cmax
hw.acpi.cpu.cx_lowest: C3 -> C8
root@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140505135809.Y11699>