Date: Tue, 19 Jun 2012 09:02:08 -0700 From: Sean Bruno <seanbru@yahoo-inc.com> To: freebsd-acpi@freebsd.org Subject: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing. Message-ID: <1340121728.5203.8.camel@powernoodle>
next in thread | raw e-mail | index | archive | help
I've noted that a lot of servers/laptops are advertising Cstates C1 and C3, but not C2 nowadays. I'm not clear if the code is causing failures to drop into C3, but it sure doesn't look right to me. More or less, this is due to the code making assumptions that the index into the cpu's array of Cstates is complete and is non-sparse (e.g. element 0 is C1, element 1 is C2, element 2 is C3 ... etc). The first impact of this behavior is to list C3 as C2 in the list of Cstates when you retrieve the cx_supported sysctls for the cpus. The second impact is that the power_profile script never drops to a valid Cstate when you set the economy_lowest variable in rc.conf. I've attempted to patch this with the following patchset to acpi_cpu.c and to the power_profile rc.d script. With these patches, I can set my power_profile to economy and the system does indeed drop into C3 saving around 25watts as measured on a Dell R410 with stable/9. The attempt here is to try and eliminate the comparisons between the index in the array of Cstates and the value of the Cstate. This patchset is against HEAD and has been tested on the R410. Does this look right to you folks? http://people.freebsd.org/~sbruno/acpi_cpu_cstate_sparse.txt Sean
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1340121728.5203.8.camel>