From owner-freebsd-arch@FreeBSD.ORG Tue Mar 18 02:23:08 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0F551065745 for ; Tue, 18 Mar 2008 02:23:08 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5A58FC1A for ; Tue, 18 Mar 2008 02:23:08 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m2I2N3gV054126; Mon, 17 Mar 2008 22:23:04 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 17 Mar 2008 16:23:48 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Poul-Henning Kamp In-Reply-To: <3860.1205764623@critter.freebsd.dk> Message-ID: <20080317161448.Q910@desktop> References: <3860.1205764623@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Power-Mgt (Was: Re: cvs commit: src/sys/i386/cpufreq est.c ) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2008 02:23:08 -0000 On Mon, 17 Mar 2008, Poul-Henning Kamp wrote: > In message <20080317141717.U3253@fledge.watson.org>, Robert Watson writes: > >> If cpufreq is going to be enabled by default, should we be enabling powerd by >> default [...] > > [Moved to arch@] > > In general, I think we must make power-aware computing our "next > SMPng project", not in the sense of delaying the next major release > five years, but in the sense that power consumption should permerate > our thinking about the operating system from now on. > > Overall, I think that means that we should: > > * Enable performance neutral power savings on servers > - spin down unused disks. (geom/drivers) > - use only as many CPU cores as necessary (scheduler) This is an interesting notion which I have tried to leave room for in the current scheduler design. One thing which I have considered in the past is a policy of best power vs best performance. For example, consider a multi-socket system with multi-core parts. With two, unrelated, runnable threads, you'll get the best perf by putting them on different sockets. Then they'll have the most cache and memory bandwidth available to them. You'd be able to spin down a socket if you put them on adjacent cores on the same socket. It's not clear that this would be a power savings however, what if each thread now runs at half the speed? Is that more power efficient than running two cores half the time? And what about the barcelona, which can power down individual cores and even individual parts of cores? And in this point to point bus topology you always need to have the dram controler and HT link on anyway. One further complication is of course that cpus can idle in different states. So someone really is going to have to explore the tradeoff between core speed, number of cores, power and performance. I think the answer to which scheduling algorithm is most power efficient is really going to come down to the cpu architecture and type of workload. This is why I have been reluctant to implement anything yet. I suspect that getting things done the fastest is going to be a good first approximation of using the least power in this regard. > - light cpu-throttling. > - downgrading 1GB to 100MB ether when idle. > > * Aim to meet or execeed energystar 4.0/5.0[1] on desktops and > plugged laptops. > - Pretty much as above, but with specific targets. > - http://www.energystar.gov/index.cfm?c=revisions.computer_spec > > * Be as battery-frugal as possible on battery driven laptops. > - Any trick in and off the book. I think these are all good goals. You should also throw in there the tickless time keeping that linux has done. We've talked about it for ages too but never gotten there. It's a shame that we keep playing catchup in these areas. Thanks, Jeff > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >