Re: powerd adaptive mode latching

Dag-Erling Smørgrav wrote:
> "Daniel O'Connor" <doconnor_at_gsoft.com.au> writes:
>> One problem with it is that it lags behind actual usage by a few
>> seconds (presumably averaging it).
> 
> It is based on the (didle/dt) / (dtotal/dt) fraction computed from
> kern.cp_time, which can take a while to ramp up.  This is not easily
> seen in a cursory reading of the code, as the fraction is computed in a
> very roundabout way.

While providing more accurate information to powerd is a good goal, I 
want to preempt any requests to move the scheduling algorithm into the 
kernel.  Until we're making multiple changes a second by necessity, 
there's no reason to have the scheduler there.  Note that inefficiencies 
in the current scheduling algorithm (2x up, 1x down) are not a cause to 
make decisions more quickly.

The path should be first fix the algorithm by profiling replacements, 
then improve the liveness of data provided to it.

>> Turning the LCD off saves about 4W too.
> 
> Hmm, it would be interesting to experiment with varying backlight
> brightness based on system load :)

I think xscreensaver could do some of this based on interactivity.  It 
already can blank the screen with dpms.  Macbooks slowly dim before 
blanking.  I often have a bg job that uses a lot of cpu (buildkernel?) 
so using cpu load wouldn't be good.

-- 
Nate