From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 11 07:22:46 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 379F9922 for ; Fri, 11 Apr 2014 07:22:46 +0000 (UTC) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2EB1107E for ; Fri, 11 Apr 2014 07:22:45 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id c41so3721204eek.8 for ; Fri, 11 Apr 2014 00:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WvW+WVYwQaxFVIlfiKKsIDX76W84+aj0FY4c+voJGZo=; b=gp8N220QwJPx1eQhGeJMn5wQ95O01XPqTLLvELj783GjJqvrROq/ZPaOdBrxiBF2P5 H9++z/VwnVERrE63DXhtTa414T1ps9T1z3gB4uw6fS2hQpr51RPIG57N5o3IzzzlkK80 gGxILZiVny+ISN5HCa+P59Pu8daAOUZB+QxmsO6f5n4DCQuAemIbZZ0jksRtMY54mtfP i9C9NHiQXq4PXJZATo7bbdAQ8b64U88Qhbz/KZ3YSNvaX0qYZ7XLhcWQXB3cvpph2E+n h58tu8+FfQmaaR53mxRmlq0kZTFxgTUGd+n1CrDrAwXVlaYlrLBYM10U3LJkcui5WuR9 9lww== MIME-Version: 1.0 X-Received: by 10.15.32.206 with SMTP id a54mr26694891eev.51.1397200963923; Fri, 11 Apr 2014 00:22:43 -0700 (PDT) Received: by 10.14.213.194 with HTTP; Fri, 11 Apr 2014 00:22:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Apr 2014 00:22:43 -0700 Message-ID: Subject: Re: C-States configuration From: hiren panchasara To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: "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 07:22:46 -0000 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? cheers, Hiren