kernel module options for cpufreq

[Dave Jones]

On Fri, Jun 27, 2008 at 09:01:34PM +0100, Richard Hughes wrote:
 > On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote:
 > > On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes <hughsient at gmail.com>
 > > wrote:
 > > > You really don't want to be using
 > > > USERSPACE at all.
 > > 
 > > seems like cpufreq-applet uses it....
 > 
 > Sure, it shouldn't. If you're using userspace for thermal or latency
 > reasons, then a setuid applet is totally the wrong way to achieve both
 > of these :-)
 > 
 > Maybe we can just use these as loadable modules (i.e. not built default)
 > rather than built-in and loaded by default.
 > 
 > DaveJ, do these suggestions seem acceptable?

Having the userspace governor built-in means absolutely nothing in terms of
overhead, until something in userspace actually uses it.

When the cpuspeed init script starts up, the first thing it does is
check if the CPU is on the whitelist for using ondemand, and if so, it
starts up ondemand.  Not a single line of the userspace governor code
gets run in this case.

The only time the above isn't true is when the CPU isn't on that whitelist,
when it's incapable of running ondemand, in which case we need to use..
ta-da... userspace, and then we start the cpuspeed process.

Again, if you're seeing overhead from using userspace, it's due to your
CPU being crap.  There's nothing we can do about it.
Whilst ondemand will load on some of these CPUs, the associated overhead
of switching is very noticable on benchmarks.

Even 'conservative' was too demanding for some of the challenged CPUs.

'crap' here doesn't mean really old stuff too.  Any pre-centrino Intel
CPU, any VIA CPU before Nehemiah generation, all mobile Athlons.

We're using ondemand on all K8's too, but the first generation also
sucked iirc, but we're just sucking it up because a) it makes the
already convoluted startup script even more messy and b) no-one can
remember which stepping/models were affected.

	Dave

-- 
http://www.codemonkey.org.uk