Date: Fri, 11 Apr 2014 12:16:23 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: Ian Smith <smithi@nimnet.asn.au> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org> Subject: Re: C-States configuration Message-ID: <CAN6yY1u4uY8MaENbnv2WVkDJgU_fqaj6se1=JPnsFDQW1EeC%2Bw@mail.gmail.com> In-Reply-To: <20140411180645.I66326@sola.nimnet.asn.au> References: <CALCpEUGxSSFRNk8jj5Mm1vVz5zWa2=B58%2B=JEybAv3rvzrZ%2BMQ@mail.gmail.com> <CAFG2KCLgXOWXsRQTXAOLgK%2BihdOU9Pp=jhX1thg_qHePUxii5g@mail.gmail.com> <CALCpEUGShjBoZ850L9KGJou4s_Onj_-oduh7Ttc4itqCB518OA@mail.gmail.com> <CAN6yY1uKST4heF1_ik=QoLaiwYiyyQKQB_yW56FrMsa_2Sy7xw@mail.gmail.com> <CALCpEUHpNuYKGs8P=b0Ap2Ft7_4xx4EM=wqBC9RnwBZje2p0YA@mail.gmail.com> <20140411180645.I66326@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 11, 2014 at 1:31 AM, Ian Smith <smithi@nimnet.asn.au> wrote: > On Fri, 11 Apr 2014 00:22:43 -0700, hiren panchasara wrote: > > On Thu, Apr 10, 2014 at 12:18 AM, Kevin Oberman <rkoberman@gmail.com> > wrote: > > > On Wed, Apr 9, 2014 at 11:22 AM, hiren panchasara > > > <hiren.panchasara@gmail.com> wrote: > > >> > > >> On Wed, Apr 9, 2014 at 11:07 AM, Anton Sayetsky <vsjcfm@gmail.com> > wrote: > > >> > 2014-04-09 20:40 GMT+03:00 hiren panchasara > > >> > <hiren.panchasara@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? > > smithi@x200:~ % x200stat > Fri Apr 11 18:24:19 EST 2014 dev.cpu.0.freq: 200 > 0.00% 2.47% 97.51% last 520us > 0.01% 2.22% 97.75% last 817us > dev.acpi_ibm.0.fan_speed: 3391 > dev.acpi_ibm.0.fan_level: 0 > dev.acpi_ibm.0.thermal: 40 44 -1 41 36 -1 35 -1 > hw.acpi.thermal.tz0.temperature: 40.0C > hw.acpi.thermal.tz1.temperature: 36.0C > State: high > Remaining capacity: 96% > Remaining time: unknown > Present rate: 0 mW > Present voltage: 12329 mV > > I'm not sure that 'at any point in time' could be very meaningful. The > above shows sysctl -n dev.cpu.0.cx_usage & sysctl -n dev.cpu.1.cx_usage > at one time - or rather at the two relativelty close times that each of > those sysctls was retrieved, both covering less than 1ms. Heisenberg's > Uncertainty Principle would most likely apply to any closer examination, > but you could chase down where the statistics are accumulated, somewhere > in cpufreq IIRC. > Since hte state changes very quickly and quite often, I agree with Ian. Don't know hat I can quite attribute it ti Heisengerg, but I can agree that trying ot look at it will distort the results, probably significantly. the fact that it is reported over times of less than 10 ms makes it clear that this changes a LOT. Adrian Chadd posted a patch to count the changes. Here is what I see after 10 seconds while quiescent: > sysctl dev.cpu.0 | grep usage dev.cpu.0.cx_usage: 8.43% 2.51% 89.05% last 1761us dev.cpu.0.cx_usage_counters: 121 36 1277 And while compiling wxgtk (i.e. the CPUs are all at near 100%): sysctl dev.cpu.0 | grep usage dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 117us dev.cpu.0.cx_usage_counters: 7 0 0 As you can see, the CPU is only occasionally halted while the compile is going on and never long enough to get past C1. When "idle" it is spending almost 90% of it's time is deep sleep (C3) and there are far more times when the CPU is halted, 1433 vs. 7. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1u4uY8MaENbnv2WVkDJgU_fqaj6se1=JPnsFDQW1EeC%2Bw>