Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Mar 2008 16:23:48 -1000 (HST)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        arch@freebsd.org
Subject:   Re: Power-Mgt (Was: Re: cvs commit: src/sys/i386/cpufreq est.c )
Message-ID:  <20080317161448.Q910@desktop>
In-Reply-To: <3860.1205764623@critter.freebsd.dk>
References:  <3860.1205764623@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
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"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080317161448.Q910>