From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 11 08:31:13 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACBAD762 for ; Fri, 11 Apr 2014 08:31:13 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 186F3179C for ; Fri, 11 Apr 2014 08:31:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s3B8V880001091; Fri, 11 Apr 2014 18:31:08 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 11 Apr 2014 18:31:08 +1000 (EST) From: Ian Smith To: hiren panchasara Subject: Re: C-States configuration In-Reply-To: Message-ID: <20140411180645.I66326@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Kevin Oberman , "freebsd-acpi@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 08:31:13 -0000 On Fri, 11 Apr 2014 00:22:43 -0700, hiren panchasara wrote: > On Thu, Apr 10, 2014 at 12:18 AM, Kevin Oberman wrote: > > On Wed, Apr 9, 2014 at 11:22 AM, hiren panchasara > > wrote: > >> > >> On Wed, Apr 9, 2014 at 11:07 AM, Anton Sayetsky wrote: > >> > 2014-04-09 20:40 GMT+03:00 hiren panchasara > >> > : > >> >> 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. cheers, Ian