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@xxxxxxxxx> > > 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list