On Thu, Apr 10, 2014 at 12:18 AM, Kevin Oberman <rkober...@gmail.com> wrote: > On Wed, Apr 9, 2014 at 11:22 AM, hiren panchasara > <hiren.panchas...@gmail.com> wrote: >> >> On Wed, Apr 9, 2014 at 11:07 AM, Anton Sayetsky <vsj...@gmail.com> wrote: >> > 2014-04-09 20:40 GMT+03:00 hiren panchasara >> > <hiren.panchas...@gmail.com>: >> >> I am running -current on my T420 at r263906M >> >> >> >> debug.acpi.acpi_ca_version: 20130823 >> >> >> >> o/p of sysctl -a | grep acpi - http://bpaste.net/show/199806/ >> >> >> >> and I have following in my rc.conf: >> >> >> >> performance_cx_lowest="Cmax" >> >> economy_cx_lowest="Cmax" >> >> >> >> But I still get: >> >> >> >> % sysctl -a | grep cx_lowest >> >> hw.acpi.cpu.cx_lowest: C1 >> >> dev.cpu.0.cx_lowest: C1 >> >> dev.cpu.1.cx_lowest: C1 >> >> dev.cpu.2.cx_lowest: C1 >> >> dev.cpu.3.cx_lowest: C1 >> >> >> >> And I can do: >> >> # sysctl dev.cpu.0.cx_lowest=Cmax >> >> dev.cpu.0.cx_lowest: C1 -> C8 >> >> >> >> that tells me that Cmax is C8. >> >> >> >> % sysctl -d dev.cpu.0.cx_lowest >> >> dev.cpu.0.cx_lowest: lowest Cx sleep state to use >> >> >> >> I was expecting cx_lowest to be set to C8 because of rc.conf config I >> >> have. >> >> >> >> What am I missing here? >> >> >> >> cheers, >> >> Hiren >> > Try to set LOW instead of Cmax. >> >> I will try it again. >> >> Interestingly enough, on an amd machine, it worked as I expected with >> a bit more current version of -head but same version of acpica: >> debug.acpi.acpi_ca_version: 20130823 >> >> cpus came up with cx_lowest set to C8 with Cmax in rc.conf >> >> cheers, >> Hiren > > > Setting Cx values is a bit confusing. Things may not mean what you think. > CMax is always C8 because this is the largest possible value of a Cx state, > not because C8 is actually available.The reason for this is that some > systems have non-sequencial Cx states. That is the maximum value my be C5, > but C2 may not be available. So the idea is to allow ANY C-state up to the > maximum. LOWEST works well as long as no states are skipped. If they are, > you are limited to the states before the skipped state. > > To see the actual available states, look at dev.cpu.0.cx_supported. > > The recommended value for best power savings is :Cmax. That will allow > skipping over missing C-states. Also, the available states often differ > between AC power and battery. On my T320: > AC dev.cpu.0.cx_supported: C1/1/1 C2/3/104 > Battery dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109
AC: hw.acpi.cpu.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/1 C2/3/104 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 8.23% 91.76% last 38us Battery: hw.acpi.cpu.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 12.35% 3.22% 84.42% last 3088us So, pretty similar on my T420 with following in rc.conf performance_cx_lowest="Cmax" economy_cx_lowest="Cmax" How do I know what C-state cpu0 is in, at any point in time? Or thats not how things work? cheers, Hiren _______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
