cpufreq and schedulers instead of powerd

[Nate Lawson]

Eric Kjeldergaard wrote:
> Hello all.  I hope this is the right place for such an item.
> 
> I've been pondering processor dynamic clocking for a while and
> recently have been wondering if it is optimal to have the processor
> rate chosen by a daemon as it is now, or rather integrate the
> downclocking into the scheduler.  My reasoning largely is based on the
> thought of overhead for switching processor speeds.  With modernish
> processors (especially the Pentium-m) it seems that the time to change
> operating frequencies is very low which would lead me to think that
> something like a scheduler could take advantage of that and clock them
> down faster and more often.  Also, schedulers (I've been looking
> mainly at ULE) have more knowledge about processor usage than just the
> current load which appears to be all that powerd looks at.  Does
> anyone have any additional information on dynamic clock handling in OS
> schedulers or information on why freebsd chose powerd over an
> implementation in scheduler(s)?

I don't want to single you out, and I do hope you'll be the one who 
follows through with actual code.  However, I wish people would stop 
talking about this and just implement it already.  This is like the 10th 
email asking the same thing.

Here is a link with references to the appropriate papers:
http://wikitest.freebsd.org/moin.cgi/powerd

To answer your specific question, more transitions != better power 
saving.  If you were idle and now have moderate CPU load, it's best to 
go to 100% to complete the work faster.  If you were busy and are now 
idle, it's best to start decreasing to the lowest level as soon as 
possible.  Total power used is the integral of instantaneous power over 
the workload.  Running a CPU bound process at the lowest frequency is 
worse than running it at 100% and then going to the lowest frequency 
once idle.

Our issue currently is not lack of quality of measurements.  It's lack 
of a good algorithm that could do better with the same measurements.  I 
don't know if you've looked at the code, but it only takes 1 measurement 
and makes all decisions based on that.  Better to have a running history 
and implement several of the algorithms and benchmark them.  Once we 
have that working, THEN it makes sense to investigate getting quality 
measurements to the algorithm.

Again, please read the history/research if you're interested in helping out.
http://wikitest.freebsd.org/moin.cgi/powerd

-- 
Nate