My experience with cpufreq in -STABLE
doconnor at gsoft.com.au
Wed Apr 6 18:19:45 PDT 2005
On Wed, 6 Apr 2005 23:31, Bruno Ducrot wrote:
> On Wed, Apr 06, 2005 at 08:49:15AM +0200, Frank Behrens wrote:
> > Bruno Ducrot <ducrot at poupinou.org> wrote on 4 Apr 2005 19:17:
> > > You may start looking at src/usr.sbin/powerd in -current, and improve
> > > it a bit? The actual algorithm used in powerd may need some rework
> > > IMHO.
> > Which problems do you see?
> powerd use an exponentional decrease of the frequency. This might be
> not stable for certain workload.
The algorithm used by the acpi_ppc module semed quite good to me when I used
it (before the frequency stuff was committed).
I have been meaning to get around to adding it to powerd.. For the moment I
just added an option to powerd to do a linear backoff instead which seems
smoother to me since I only had a limited number of steps (although I just
discovered if I load cpufreq.ko I get a lot more.. doh.. thought I'd already
done that :)
> and it seems it's maybe not the better one, though (search 'MAW', its
> exactly what you suggest).
That paper is interesting reading :)
> > 2. The default polling time of 500 ms seems to be very short. It can
> > increased to several seconds.
> Problem if you increase teh polling intervall is that you can't be sure
> that the system can detect in time when going up.
I don't think increasing the poll interval is a good idea - it means your
system will respond slowly to workload changes. However you could use
filtered averages (a la that paper) to reduce the number of speed changes.
One thing that does worry me about having a userland daemon control the speed
is that if it drops down to a really low speed after some idle time it could
take a very long time to get some CPU time. Not sure if it's a real problem
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20050407/a8e7e59a/attachment.bin
More information about the freebsd-hackers