From owner-freebsd-acpi@FreeBSD.ORG Mon May 4 12:24:32 2009 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 515741065673; Mon, 4 May 2009 12:24:32 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2E88FC14; Mon, 4 May 2009 12:24:31 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 241886311; Mon, 04 May 2009 15:24:30 +0300 Message-ID: <49FEDE7B.30804@FreeBSD.org> Date: Mon, 04 May 2009 15:24:27 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <49FE1826.4060000@FreeBSD.org> <1241438990.1280.6.camel@RabbitsDen> In-Reply-To: <1241438990.1280.6.camel@RabbitsDen> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD acpi , FreeBSD-Current , freebsd-mobile@freebsd.org Subject: Re: Fighting for the power. 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: Mon, 04 May 2009 12:24:33 -0000 Alexandre "Sunny" Kovalenko wrote: > On Mon, 2009-05-04 at 01:18 +0300, Alexander Motin wrote: >> - C3 state allows CPU completely stop all internal clocks, reduce >> voltage and disconnect from system bus. This state gives additional >> power saving effect, but it is not cheap and require trade-offs. >> As soon as CPU is completely stopped in C3 state, local APIC timers in >> each CPU core, used by FreeBSD as event sources on SMP, are not >> functioning. It stops system time, breaks scheduling that makes system >> close to dead. > Did you try to see whether putting one of the cores in C3 state by doing > something like > > dev.cpu.1.cx_lowest=C3 > > makes any difference? > > # sysctl dev.cpu | grep cx_usage > dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% > dev.cpu.1.cx_usage: 0.00% 5.18% 94.81% I did. As soon as first CPU core is not in C3 state, second core unable to enter C3 completely and disconnect from the bus, as cores are sharing common resources. Such technique allows to avoid LAPIC timer problems, but I haven't noticed any effect from this on CPU idle power. The only difference I have noticed was in the case, when first core is busy. C3 on second idle core then somehow reduces summary consumption a bit. In other words, C3 state should be active on both cores simultaneously to give real effect. -- Alexander Motin