Power-Mgt (Was: Re: cvs commit: src/sys/i386/cpufreq est.c )
Jeff Roberson
jroberson at chesapeake.net
Tue Mar 18 02:23:08 UTC 2008
On Mon, 17 Mar 2008, Poul-Henning Kamp wrote:
> In message <20080317141717.U3253 at 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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>
More information about the freebsd-arch
mailing list