From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 19 16:02:57 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96283106564A; Tue, 19 Jun 2012 16:02:57 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5048FC1A; Tue, 19 Jun 2012 16:02:57 +0000 (UTC) Received: from [IPv6:::1] (proxy6.corp.yahoo.com [216.145.48.19]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q5JG29AC014932; Tue, 19 Jun 2012 09:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1340121732; bh=HnLTb6VevXDp7Lsz1t5JxMKksXBk5vCxx1OEYFCB8Uk=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=lRjLio3hrGrABJES5HyqbjnlO18JBqggIJlQYQRL3osGNlZRwzNl+4Dd5ZzH0XUnV OrpSzoFoYNsSAbj1/9b8m3eEGvDUseT7WuAlONE+pKBeMHpWfwNW8iQKR6Npf77b1l Vpwe9cMPWIbnUKNMCtSglqXgJAhUeoTAN7LIuGg8= From: Sean Bruno To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Tue, 19 Jun 2012 09:02:08 -0700 Message-ID: <1340121728.5203.8.camel@powernoodle> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 121730001 Subject: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 16:02:57 -0000 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