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

[Dominik Brodowski <linux@brodo.de>]

On Tue, Oct 21, 2003 at 10:38:53AM +0200, Arjan van de Ven wrote:
> Note that I'm not totally against doing some of this in the kernel; I
> can well see the point of say, detecting an IRQ overload and based on
> that, go to max speed in the kernel because it's a situation where
> userspace doesn't even run; but the patch as is doesn't do any such
> advanced things...

Indeed, this driver doesn't do anything like that. However,  I want to point
out two [of more] reasons why this is the right thing to do:

1.) I'm aware of one embedded system running linux which only has two 
userspace programs - busybox and cardmgr. All other stuff is handled 
in the kernel. An effort to remove the dependency on cardmgr is going on
[ <linux-pcmcia@lists.infradead.org> ]. If this embedded system was
supporting cpufreq, would you want to do dynamic scaling in the kernel, or
in userspace?

2.) It's a starting point for more advanced governors which really cannot be
done in userspace as this would be much too expensive. Having to choose
between different kernel and different userspace governors seems a bit
complicated for me. The _cost_ of doing this specific governor in the kernel
is near zero.

	Dominik