cvs commit: src/usr.sbin/powerd powerd.c

[Nate Lawson]

Hajimu UMEMOTO wrote:
>>>>>>On Wed, 24 Aug 2005 20:14:42 +0900
>>>>>>Hajimu UMEMOTO <ume at FreeBSD.org> said:
> 
> ume> It feels too lazy for my laptop.  One freq level for decreasing and
> ume> two freq level for incresing is comfortable to me.
> 
> Oops, I meant two and four.
> Because, my main laptop has double CPU levels than my second laptop.
> So, it takes double iteration for transition from highest to lowest or
> from lowest to highest.

Hello, I am back from vacation.  As Kevin and Bruno will attest, I was 
not happy to go down this path since you can't make everyone happy 
without a proper predictive algorithm.  For small numbers of levels, 
this algorithm works fine.  For large numbers of levels, it can 
oscillate just as much as the previous algorithm when there is a 
periodic load.  I do not think you should add an option to tune the 
parameters as this algorithm should be removed as soon as we have 
something better.  I don't want to make it permanent by adding 
user-visible flags.

The right fix is the project that was started by a Summer of Code 
participant to profile a set of predictive algorithms and choose the 
best.  Some good background info about this is here if someone wants to 
take up this task:

http://wikitest.freebsd.org/moin.cgi/powerd

Another mitigating factor is a patch I hope to commit soon that removes 
levels that aren't useful.  The general idea is the same as a recent 
email from Tijl Coosemans but my approach is different.

-- 
Nate