RFC: powerd algorithms enhancements

[Ian Smith]

On Wed, 5 Nov 2008, Alexander Motin wrote:
 > Hi.

Hi, sounds like sound's more or less under control, time on your hands? :)

 > I would like to propose the patch for powerd that fixes some issues, makes it
 > more universal and on my opinion more usable. The main ideas of mine were:
 > 
 > 1. To make it more SMP polite. Previous version uses average CPU load that
 > leads to the often load underestimation. It make powerd with default
 > configuration unusable on systems with more then 2 CPUs. I propose to use
 > summary load instead of average one. IMO this is the best we can do without
 > specially tuned scheduler. Also as soon as measuring total load on SMP
 > systems is more useful then total idle, I have switched to it.

Ok, very interesting.  First, is this against CURRENT, or to what CVS 
version, so I can read patched version in full?  Any change to .h files?

 : --- powerd.c.prev       2008-07-29 21:51:52.000000000 +0300
 : +++ powerd.c    2008-11-05 22:51:35.000000000 +0200
 : @@ -50,13 +50,14 @@ __FBSDID("$FreeBSD: src/usr.sbin/powerd/


 > 2. To make powerd's operation independent from number and size of frequency
 > levels I have added internal frequency counter which translated into real
 > frequencies only on a last stage and only as good as gone. Some systems may
 > have only several power levels, while mine has 17 of them, so adaptation time
 > in completely different. It would be good if algorithm was not depending on
 > it.

There were some XXX comments re longterm allowance for running different 
cpus at different freqs .. I don't know if that's anything to consider?

 > 3. As part of previous I have changed adaptive mode to rise frequency on
 > demand up to 2 times and fall on 1/8 per time internal.

I'm wondering how the edge case with only 2 freqs would go?  Eg on my 
T23, single cpu P3 Mobile at 1133 and 733MHz.  That is, I'm wondering if 
your 1/8 factor might better be scaled to no. of cpus and/or no. of 
freqs available?  I'd best say no more until studying your algorithm ..

 > 4. For desktop (AC-powered) systems I have added one more mode -
 > "hiadaptive". It rises frequency twice faster, drops it 4 times slower,
 > prefers twice lower CPU load and has additional delay before leaving the
 > highest frequency after the period of maximum load. This mode was specially
 > made to improve interactivity of the systems where operation capabilities are
 > more significant then power consumption, but keeping maximum frequency all
 > the time is not needed.

Great idea.  And one (not so) small step towards some proper profiles, 
where various degrees of performance vs responsiveness vs power use can 
be setup by the user .. extending now binary AC/battery power_profile 
choices (starting freq, lowest Cx state), later perhaps tying in with 
the shutdown/wakeup stuff for both system and individual devices (eg D 
states).  Sorry, just musing aloud .. this has needed a kick for ages :)

 > 5. I have reduced polling interval from 1/2 to 1/4 of second. It is not
 > important for algorithm math now, but gives better system interactivity.

You mean the default polling interval I guess, as it's tuneable at least 
on powerd startup, as are the loaded/idle points, which as someone else 
mentioned, might be more dynamically modified while powerd is running?

I guess jhb is in this loop?  Most powerd dev has been in acpi@ at least 
to date, and I gather there's a fair overlap of participants, but I best 
not presume too much .. sam's concerns seem tied in with the same kernel 
cpu freq setting stuff, so I gather all that is connected long term ..

Then if you get really bored :) SMP suspend/resume and S4 suspend to 
disk need a champion .. both of which have at least begun in acpi at .

cheers, Ian