2010-05-13 00:41:28 +02:00
|
|
|
Overview:
|
2010-05-12 23:33:46 +02:00
|
|
|
This is a very simple program that will adjust the speed of your CPU
|
|
|
|
depending on system load. It works as a client of the CPUFreq driver.
|
2010-05-13 00:41:28 +02:00
|
|
|
It is designed for use with CPU's supporting AMD's PowerNow power management
|
|
|
|
scheme, as it's algorithm works better if there are more then two CPU
|
|
|
|
speeds available. (aka, ARM, AMD K6/K7, Via C3, and Crusoe as opposed to
|
|
|
|
traditional Intel and Ultrasparc).
|
2010-05-12 23:33:46 +02:00
|
|
|
|
2010-05-13 00:41:28 +02:00
|
|
|
This program is essentially a simple client to the CPUFreq sysfs interface.
|
|
|
|
This means that you -need- to be running Linux v2.5 or later that includes
|
|
|
|
the sysfs interface. This daemon will -not- work with the CPUFreq driver
|
|
|
|
interface included in Linux v2.4. Feel free to write your own daemon
|
|
|
|
to support that if you like; you can even use this as a starting point.
|
|
|
|
If there's enough clamoring for it, then maybe I'll whip up something.
|
|
|
|
You also need a CPU that supports frequency scaling and supports the CPUFreq
|
|
|
|
interface. This code has been tested on various AMD and PPC processors
|
2010-05-12 23:33:46 +02:00
|
|
|
|
2010-05-13 00:41:28 +02:00
|
|
|
I have been running this daemon on my AMD laptop for over 2 years with no
|
|
|
|
problems to report, and it's nice that my laptop remains cool unless I'm
|
|
|
|
really doing something intensive, like watching DivX movies, without me
|
|
|
|
having to manually intervene and set the speed. I just recently bought an
|
|
|
|
Apple iBook G3, and powernowd-0.80 worked flawlessly on it right out of
|
|
|
|
the box.
|
|
|
|
|
|
|
|
|
|
|
|
Features:
|
|
|
|
|
|
|
|
This daemon's goal is simplicity and speed. It doesn't try and make
|
|
|
|
too many decisions for you. That's its beauty, but it may not be what
|
|
|
|
everyone's looking for. Some of the features this daemon has:
|
|
|
|
|
|
|
|
One, simple heuristic to determine CPU load: "user + sys" time.
|
|
|
|
Ignore "niced" programs (setiathome, itself, etc). In my mind this is
|
|
|
|
consistent with what is meant when someone 'nice's a program to begin
|
|
|
|
with. (configurable in v0.85+) Designed for CPU's that support more
|
|
|
|
then two speed states, but works well with anything. Very fast, low
|
|
|
|
overhead /proc/stat gathering (method stolen from procps). Supports SMP
|
|
|
|
Will automatically switch to 'userspace' governor. Care taken to make
|
|
|
|
the code non-root exploitable (but please audit for yourself first!)
|
|
|
|
Frequency step size is configurable (default to 100MHz/step) 4 different
|
|
|
|
behavioral modes to choose from (SINE, AGGRESSIVE, PASSIVE, LEAPS),
|
|
|
|
which determine the behavior when the load changes. Configurable from the
|
|
|
|
command line. Written in C for speed and simplicity. Logging to stdout
|
|
|
|
or syslog Configurable Polling frequency in milliseconds (defaults to 1s)
|
|
|
|
Configurable highwater/lowwater marks for CPU usage. (defaults 80/20%)
|
|
|
|
|
|
|
|
Many similar daemons use other methods to determine what speed to use,
|
|
|
|
such as battery status, AC status, temperature, fan status, etc. They all
|
|
|
|
have their place. I however feel that in the grand scheme of things none
|
|
|
|
of the above matters. When I'm not using my CPU, I don't care if it's
|
|
|
|
running at a slower speed. When I -am- using my CPU, I only need it to
|
|
|
|
be fast enough to handle the task at hand without hiccuping. And when I'm
|
|
|
|
taxing my CPU, I want it running full speed. That's all this daemon does,
|
|
|
|
monitor CPU load and adjust the speed accordingly. Since in all reality
|
|
|
|
my CPU is idle 99% of the time (or playing mp3's which it can easily do
|
|
|
|
at it's lowest speed rating), this by definition leads to low power usage,
|
|
|
|
low temperatures, low speed fans, and better battery life.
|