From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 20 05:00:55 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 115CC1065670; Wed, 20 Jun 2012 05:00:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6F78FC0C; Wed, 20 Jun 2012 05:00:53 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA18521; Wed, 20 Jun 2012 08:00:49 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ShD29-000EDn-Bz; Wed, 20 Jun 2012 08:00:49 +0300 Message-ID: <4FE158FF.5070209@FreeBSD.org> Date: Wed, 20 Jun 2012 08:00:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: Sean Bruno References: <1340121728.5203.8.camel@powernoodle> <4FE0EA24.6000906@FreeBSD.org> <1340142162.3201.12.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1340142162.3201.12.camel@powernoodle.corp.yahoo.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "sbruno@freebsd.org" , "freebsd-acpi@freebsd.org" Subject: Re: [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 List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 05:00:55 -0000 on 20/06/2012 00:42 Sean Bruno said the following: > On Tue, 2012-06-19 at 14:07 -0700, Andriy Gapon wrote: >> on 19/06/2012 19:02 Sean Bruno said the following: >>> 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. >> >> I do not think that this is a real problem. A cosmetic one - most likely. >> > Yes, most likely. Except that the code seems to think that the index of > the Cstates is good enough for a comparison to value. More over, the > sysctl's accept a value like "C3" and manipulate that into an index into > the Cstate array without checking for the Cstate value. > > The impact of this patch corrects this cosmetic display issue. If you accept that there are "FreeBSD C-states" and everything is done in terms of them, then there is no problem. I once wrote this trivial patch to see more information about FreeBSD-reported C-states: https://gitorious.org/~avg/freebsd/avgbsd/commit/043e9b0da5b46d389971e0166789fbee8a4e8622?format=patch >>> 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. >> >> Could you please explain if this somehow follows from your first observation and >> how? >> If not, could you please share your finding on what exactly causes this to happen? >> >> Also, are we talking about a laptop here? Namely, judging from the reference to >> 'economy_lowest', are AC state changes in play? >> > > No, what I was attempting to do was configure a server such that it > would attempt to use the C3 state at idle. Since the server gets > configured by the power_state scripts via devd, the server is never > configured with its global cx_lowest as anything other than C1. e.g: > > -bash-4.2$ sysctl -a|grep cx_lowest > hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_lowest: C1 > dev.cpu.1.cx_lowest: C1 > > -bash-4.2$ sysctl -a|grep cx_supported > dev.cpu.0.cx_supported: C1/1 C2/96 > dev.cpu.1.cx_supported: C1/1 C2/96 > > > It seems that the rc.conf value of performance_cx_lowest="LOW" is what I > really want, not economy_cx_lowest. Yes. Could you please try this without using your patch? I get an impression that its effect was to actually request C2 when cx_lowest is set to C1. -- Andriy Gapon