We believe that your issue has been closed by the upload of
Version 0.9.1 of grml-autoconfig from Michael Prokop <mika@grml.org>.
The explanation is attached below

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 14 Nov 2009 13:27:52 +0100
Source: grml-autoconfig
Binary: grml-autoconfig
Architecture: source all
Version: 0.9.1
Distribution: unstable
Urgency: low
Maintainer: Michael Prokop <mika@grml.org>
Changed-By: Michael Prokop <mika@grml.org>
Description: 
 grml-autoconfig - main bootup process of a grml system
Changes: 
 grml-autoconfig (0.9.1) unstable; urgency=low
 .
   * Use lang=en as default (instead of lang=us). [Closes: issue760]
   * Enable cpu frequency scaling on all hardware by default (and
     don't limit it to laptops only). Thanks for bringing this
     up, Andras Korn! [Closes: issue754]
Checksums-Sha1: 
 a5d25a3c310bd2705bba2320661a3518f21e41a0 931 grml-autoconfig_0.9.1.dsc
 c47ebe5fdead50e8eeecbb24dfc7a1f80154fd6b 80147 grml-autoconfig_0.9.1.tar.gz
 5afcbe5d162bd94b621a2e4018a395fca018dd3c 94576 grml-autoconfig_0.9.1_all.deb
Checksums-Sha256: 
 052abbffaef659d8e58e2a0bcb724ef5d0031eb75ec540ab531066e02dc81e04 931 grml-autoconfig_0.9.1.dsc
 152022efb33243435af9308aed0744840428320cb17a9ee523365fea7b9da6a5 80147 grml-autoconfig_0.9.1.tar.gz
 7732017fac1c1b8b0dd4e617318700e9c26d571fdd1fbee43a3905bef5a00449 94576 grml-autoconfig_0.9.1_all.deb
Files: 
 737a633c5dac6dba71d6b504272caf0e 931 grml optional grml-autoconfig_0.9.1.dsc
 e498d8efd0a056b7d4527949d7d70161 80147 grml optional grml-autoconfig_0.9.1.tar.gz
 7677e7343404a2dc7c312a600ae1044a 94576 grml optional grml-autoconfig_0.9.1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFK/qKz2N9T+zficugRAqeyAJ9e+zy+Kwn7F5khLTt8wMkNHLoL8gCfTbvH
vEUsszhxAyzhtLS2/2tDgIY=
=2OIz
-----END PGP SIGNATURE-----

On Friday 30 October 2009 00:34:41 Andras Korn wrote:

> My wish then is for cpu frequency scaling to be enabled by default when
>  possible (maybe except if inhibited on the kernel command line).

Second that as the ondemand governor does a good job.

Ulrich

* Andras Korn <bts@bts.grml.org> [20091030 00:53]:
> Andras Korn <korn-grml@elan.rulez.org> added the comment:

> > We had some annoying problems with performance when using
> > cpufrequency scaling on non-mobile systems in the past.

> Maybe that was in the P4 age, with powernowd? That I could understand.

Yeah, around that. :)

> I run all my reasonably modern systems (mostly Athlon*/Phenom/Opteron, with a
> few core2duo and xeon based ones) with the ondemand governor and haven't really
> noticed anything wrong. (With the possible exception of the clock in virtualbox
> being waaaaaaaaaay slow on one system, but I'm not yet sure that has anything to
> do with cpu frequency scaling at all.)

> Just my 2 cents.

Ok, thanks for information.

regards,
-mika-

> We had some annoying problems with performance when using
> cpufrequency scaling on non-mobile systems in the past.

Maybe that was in the P4 age, with powernowd? That I could understand.

I run all my reasonably modern systems (mostly Athlon*/Phenom/Opteron, with a
few core2duo and xeon based ones) with the ondemand governor and haven't really
noticed anything wrong. (With the possible exception of the clock in virtualbox
being waaaaaaaaaay slow on one system, but I'm not yet sure that has anything to
do with cpu frequency scaling at all.)

Just my 2 cents.

Andras

* Andras Korn <bts@bts.grml.org> [20091030 00:34]:

> > Grml has it's mechanisms to load the cpufreq drivers, but activates
> > it only if a laptop has been detected. Is your system a laptop?

> Oh. No, no laptop; but why not save power on all computers by default? It's good
> for the environment, generates less heat etc. etc.

> With the ondemand governor, and for (my :) typical uses of grml, the performance
> loss is negligible.

We had some annoying problems with performance when using
cpufrequency scaling on non-mobile systems in the past.

> > Does running 'Start loadcpufreq' (corresponds with
> > '/etc/init.d/loadcpufreq start') address your issue?

> Probably; I didn't know of this script, but will try it the next time I boot
> grml somewhere. So far I just modprobed and echoed away (zsh makes it so easy
> even when you have many cores - echo ondemand >/sys/**/scaling_governor :).

:)

> My wish then is for cpu frequency scaling to be enabled by default when possible
> (maybe except if inhibited on the kernel command line).

Ok, we will investigate on that and check whether enabling
cpufrequency by default would be an option for the upcoming
releases.

Thanks for your input.

regards,
-mika-

> Grml has it's mechanisms to load the cpufreq drivers, but activates
> it only if a laptop has been detected. Is your system a laptop?

Oh. No, no laptop; but why not save power on all computers by default? It's good
for the environment, generates less heat etc. etc.

With the ondemand governor, and for (my :) typical uses of grml, the performance
loss is negligible.

> Does running 'Start loadcpufreq' (corresponds with
> '/etc/init.d/loadcpufreq start') address your issue?

Probably; I didn't know of this script, but will try it the next time I boot
grml somewhere. So far I just modprobed and echoed away (zsh makes it so easy
even when you have many cores - echo ondemand >/sys/**/scaling_governor :).

My wish then is for cpu frequency scaling to be enabled by default when possible
(maybe except if inhibited on the kernel command line).

Andras

* Andras Korn <bts@bts.grml.org> [20091030 00:05]:

> grml64 2009.05 (and I believe also 32bit grml) fails to load the cpufreq driver
> module (in most cases powernow-k[78] or acpi-cpufreq), which results in a waste
> of electric power until the user does it by hand. (Setting the scheduler to
> ondemand manually may also be necessary; I've grown accustomed to doing it no
> matter what, so I'm not sure grml doesn't do it for me.)

> Would there be any harm in just trying to load all cpufreq drivers? Or at least
> the most common ones? (I'm not sure complex auto-detection is warranted if udev
> doesn't do it on its own.)

Grml has it's mechanisms to load the cpufreq drivers, but activates
it only if a laptop has been detected. Is your system a laptop?

Does running 'Start loadcpufreq' (corresponds with
'/etc/init.d/loadcpufreq start') address your issue?

regards,
-mika-

Hi,

grml64 2009.05 (and I believe also 32bit grml) fails to load the cpufreq driver
module (in most cases powernow-k[78] or acpi-cpufreq), which results in a waste
of electric power until the user does it by hand. (Setting the scheduler to
ondemand manually may also be necessary; I've grown accustomed to doing it no
matter what, so I'm not sure grml doesn't do it for me.)

Would there be any harm in just trying to load all cpufreq drivers? Or at least
the most common ones? (I'm not sure complex auto-detection is warranted if udev
doesn't do it on its own.)

Andras