From owner-freebsd-stable@FreeBSD.ORG Fri Apr 8 17:52:43 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 514AC106564A; Fri, 8 Apr 2011 17:52:43 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF54B8FC0A; Fri, 8 Apr 2011 17:52:42 +0000 (UTC) Received: by wyf23 with SMTP id 23so3792550wyf.13 for ; Fri, 08 Apr 2011 10:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Tl+BxZ8FMbdQr6O2aWIuPB0DqsJQCL7/N8KCcGYpDNI=; b=VRTE3EiSAh4ScvYD3hKsxSzII6xI2tKff+5pha+DpUGrzUPmkFCtgUQ75XKpeoBa3H jPAJ+imSSgdNe8wgqOGpJcEqelv2+2NQ7bGVB67LMAMz1iasNAZsX3WGR7LLXxQ9Hug/ TAlBdrj/8iIaKgPiL0z4+t6yFtNr1Oo1SSaJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=TAPOOYuLneuICe2bMbYl5ffwCelGYozVkFVkFpqu8UmwrwWfFJAyitKbP645wfxmrc U0GAiRmMubgiq5DyD0zto2rTyheiI95ArZNuFPlc/XNM2pu8ZEhMM5iL4DYEU2c1JDQ+ tf7BegfA9Kqr2PItjOTMvVATEfbjnDJGrfRFg= Received: by 10.216.62.74 with SMTP id x52mr2427058wec.45.1302285161619; Fri, 08 Apr 2011 10:52:41 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (95-109-196-139.dialup.umc.net.ua [95.109.196.139]) by mx.google.com with ESMTPS id d54sm1472451wej.10.2011.04.08.10.52.36 (version=SSLv3 cipher=OTHER); Fri, 08 Apr 2011 10:52:40 -0700 (PDT) Sender: Alexander Motin Message-ID: <4D9F4B58.3050104@FreeBSD.org> Date: Fri, 08 Apr 2011 20:52:24 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110310 Thunderbird/3.1.9 MIME-Version: 1.0 To: Daniel Gerzo References: <4D9EEDAF.3020803@rulez.sk> <4D9EF48C.9070907@FreeBSD.org> <4D9F2384.5000104@FreeBSD.org> <85cda6f83d328e67a552b2cd5758dbd3@rulez.sk> In-Reply-To: <85cda6f83d328e67a552b2cd5758dbd3@rulez.sk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org Subject: Re: powerd / cpufreq question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:52:43 -0000 On 08.04.2011 19:53, Daniel Gerzo wrote: > On Fri, 08 Apr 2011 18:02:28 +0300, Alexander Motin wrote: >>> OK, I understand what you are saying here. On the other side, I know >>> pretty well how the load is distributed - in this particular case, the >>> box is a web server, running ~30 php-cgi processes. >>> This kind of operation doesn't require very high frequency and I suspect >>> the cores are never waiting for each other. There could be an option >>> which would allow an administrator to decide whether this is the case >>> and allow him to set a higher -r and -i values, what do you think? >> >> I think it should be possible with minimal changes. > > So, here is my attempt to implement it: > http://danger.rulez.sk/powerd.diff > Can you please review & comment? I should be able to commit it mysqlf if > you consider it acceptable. It seems to work for me :) Looks fine, except that -f option have to be the first, that is not obvious. Another moment -- I've noticed some load constants hardcoded there. They should also be handled to make higher values to work properly. >>> Any idea what I should look for in the BIOS? >> >> Something about C-states, or Cx-states on the CPU page. But first >> look at dev.cpu.X.cx_supported to make sure it is not already present >> and just unused. > > Seems like it was enabled by default. I have like these: > dev.cpu.0.cx_supported: C1/3 C2/96 C3/128 > > Does that mean I only need to set these in rc.conf?: > performance_cx_lowest="C3" > economy_cx_lowest="C3" > > Then run /etc/rc.d/power_profile 0x00? It short - yes. In long - read the link I've given. > May it cause any instability? It you won't switch from LAPIC to other timer and it stop - your system will freeze, or at least not work well. You should notice problems immediately, if there are. >>> This is 8-STABLE, any idea whether there's a MFC plan for the extra >>> 9-CURRENT bonuses? >> >> I suppose around May. > > Do you have some patches? If not you don't really need to make them just > for me, I can wait a little. Last ones I've generated are five months old: http://people.freebsd.org/~mav/timers_merge/ They are large and I am not sure how good they apply now. >>>> You may want to look here: >>>> http://wiki.freebsd.org/TuningPowerConsumption >>> >>> From reading this, are you reffering above to the C2 states? (seems >>> like C3 is not optimal for this kind of operation...) >> >> The deeper state, the more power saved. To get most of it and to get >> TurboBoost working you need at least C3 CPU state (ACPI may report it >> with different number). Some latest Intel CPUs have no described >> problems with C3 and LAPIC, for others described system tuning >> requited. > > I believe this is pretty recent CPU (6 core Xeon X5650). Do you know > about any problems? I have no idea about these Xeons. I know just that LAPIC of the my Core i5 works fine in C3, while one of the my Core i7 doesn't. >> PS: Using powerd in best case wont hurt performance, while using >> C-states may even increase it in some cases because of TurboBoost. > > If I want to use C-states, should I stop to use powerd, or is it > possible to use them both together? I am using both together on my laptop. -- Alexander Motin