RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-statedriver

RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-statedriver

[Moore, Robert]

This is exactly what I was looking at doing, looks like most of the work
is done.  I have some concerns about the actual algorithm used for
changing the CPU frequency (20%/80%), but this of course can be tuned.

I suspect that CPUs that have the capability of changing frequency
themselves would not use this particular governor.

You may want to make the sampling rate configurable at run time.

Bob


-----Original Message-----
From: Pallipadi, Venkatesh 
Sent: Monday, October 20, 2003 7:57 PM
To: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org; linux-acpi
Cc: Mallick, Asit K; Nakajima, Jun; Dominik Brodowski
Subject: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI
P-statedriver

Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-statedriver

[Dominik Brodowski]

On Tue, Oct 21, 2003 at 10:12:14AM -0700, Moore, Robert wrote:
> 
> This is exactly what I was looking at doing, looks like most of the work
> is done.  I have some concerns about the actual algorithm used for
> changing the CPU frequency (20%/80%), but this of course can be tuned.

Well, so write a different governor, and feel free to use Venkatesh's code
as a base [it's GPLed, after all...]. I prefer to have several different 
governors available, so that different users with different needs
can use different "policies".

> I suspect that CPUs that have the capability of changing frequency
> themselves would not use this particular governor.

They can't -- If the driver for Transmeta CPUs is loaded, 
cpufreq governors cannot be started.
 
> You may want to make the sampling rate configurable at run time.

Such a "tweaking by sysfs" patch can be added later.

	Dominik