From owner-freebsd-stable@FreeBSD.ORG Fri Apr 8 14:58:39 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 6C5F31065673 for ; Fri, 8 Apr 2011 14:58:39 +0000 (UTC) (envelope-from hosting@syscare.sk) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id EC01F8FC18 for ; Fri, 8 Apr 2011 14:58:38 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id E8A9494140; Fri, 8 Apr 2011 16:42:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id HJ1sj8t7mTPA; Fri, 8 Apr 2011 16:42:42 +0200 (CEST) Received: from hosting.syscare.sk (hosting [188.40.39.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by services.syscare.sk (Postfix) with ESMTPS id 92F4A9410F; Fri, 8 Apr 2011 16:42:42 +0200 (CEST) Received: (from www@localhost) by hosting.syscare.sk (8.14.4/8.14.4/Submit) id p38Egg0W035596; Fri, 8 Apr 2011 16:42:42 +0200 (CEST) (envelope-from hosting@syscare.sk) X-Authentication-Warning: hosting.syscare.sk: www set sender to hosting@syscare.sk using -f To: Alexander Motin X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Apr 2011 15:42:42 +0100 From: Daniel Gerzo Organization: The FreeBSD Project In-Reply-To: <4D9EF48C.9070907@FreeBSD.org> References: <4D9EEDAF.3020803@rulez.sk> <4D9EF48C.9070907@FreeBSD.org> Message-ID: X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.5.1 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 14:58:39 -0000 On Fri, 08 Apr 2011 14:42:04 +0300, Alexander Motin wrote: Hello Alexander, thanks for quick reply; >> root@[s1-a ~]# powerd -v -r 1000 -i 600 >> powerd: 1000 is not a valid percent >> >> Well, that makes sense, but why powerd itself knows about load > >> 100% >> but doesn't allow me to specify it? Is this bug? I suppose not if it >> works for other people... > > It is reasonable limitation. powerd can't know how load distributed > among multiple cores in time. If all cores are equally busy at lets > say 10% (that gives 120% total) and cores are never waiting for each > other then obviously frequency could be reduced. But if the same 120% > mean 100%+20%, or if load is equally spread, but processes on > different cores are waiting for each other, then reducing frequency > will reduce performance. powerd can't know that and so stays on a > safe > side. 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? >> Other question would be why powerd wants to set freq 5336, when it >> is >> not available at all (would be nice to have it heh.): > > You may see there it is a "wanted" frequency, not real one. :) It is > internal implementation details. In such way powerd implements > keeping > a full frequency for some time after the load dropped. It's not a > bug. OK :-) I actually though powerd always honors the values from dev.cpu.0.freq_levels (and 5336 is not there), so it looked a little weird to me. > On multi-core systems like this power management can better be done > on per-core bases. Powerd can't control frequencies on per-core basis > (also because it require non-trivial interoperation with scheduler). > But if your ACPI BIOS allows, you can try to put unused cores into > deeper C-states, that may give better power saving and TurboBoost on > busy cores as a bonus. It works better on 9-CURRENT, but on 8-STABLE > some bonuses still could be achieved. Any idea what I should look for in the BIOS? This is 8-STABLE, any idea whether there's a MFC plan for the extra 9-CURRENT bonuses? > 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...) Thanks. -- Kind regards Daniel