On Mon, 2006-07-10 at 22:08 +0200, Simen Thoresen wrote:

Hi all,

I think I've spotted a few stupidities (bugs) in the current version of kernel-utils (kernel-utils-2.4-13.1.80). <snip>

The kernel-utils package provides several 'kernel-type' functions - readahead and readahead_early and also the cpuspeed have a few problems;

readahead 'reads ahead' (stats to copy to cache for speedy access?) the files found in /etc/readahead.files. While most of these files are various images and common binaries, some are libraries which have been replaced by newer versions, thereby reducing the usefulness of readahead.

Readahead.early uses a different file (/etc/readahead.early.files) to cache useful system libraries, including a few kernel modules - for the 2.6.3-2.1.238.2 kernel.

Both readahead and readahead.early are installed as disabled. chkconfig lists them as 'off' in all runlevels.

<snip>

In a thread about undesirable swapping in the last few weeks, one poster suggested disabling both read-ahead processes entirely. This was for workstations. He claimed that he could see no difference in his normal daily operations when read-ahead was enabled. The benefit was that he no longer came to a grinding halt after a few days of sporadic heavy load when swap usage skyrocketed for no discernible reason.

It also became known in that thread that a brain-damaged "feature" related to VM swapping was going to be fixed in update 4 (IIRC). Further, the ill-effects of this could be reduced by setting a value that reduced "swappiness" of the system. Anyway, since disabling readaheads, swap usage never exceeded 768K. User is no fatter, no dumber but is much happier as lock up occurrences are once again below the levels expected in a M$ system! zzzziiiing! :-)

On Mon, 2006-07-10 at 22:08 +0200, Simen Thoresen wrote:

Hi all,

I think I've spotted a few stupidities (bugs) in the current version of kernel-utils (kernel-utils-2.4-13.1.80). I'm sure these are all propagated from upstream, but I hope someone could have a quick look to verify this and see if we either can push complaints upwards, or provide local fixes.

The kernel-utils package provides several 'kernel-type' functions - readahead and readahead_early and also the cpuspeed have a few problems;

readahead 'reads ahead' (stats to copy to cache for speedy access?) the files found in /etc/readahead.files. While most of these files are various images and common binaries, some are libraries which have been replaced by newer versions, thereby reducing the usefulness of readahead.

Readahead.early uses a different file (/etc/readahead.early.files) to cache useful system libraries, including a few kernel modules - for the 2.6.3-2.1.238.2 kernel.

Both readahead and readahead.early are installed as disabled. chkconfig lists them as 'off' in all runlevels.

Worse, cpuspeed. This is from an Athlon64 system, so it is possible that this behavior is different on non powernow-k8 systems.

On the CentOS4-x86_64 kernels, the cpuspeed-drivers are built into the kernel. Here, cpu speed-management works, as the /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver -file exists (tested for in /etc/init.d/cpuspeed). On CentOS4-i386, the powernow-k8-module is not built into the kernel, so the above test fails, and the cpuspeed startscript exits.

There seems to be a plan for this. The /etc/cpuspeed.conf file can specify a DRIVER variable, but no attempt is made to insmod this, so even if this is set, cpuspeed still fails. A simple fix is to check for the presence of the above /sys entry, and if that is missing, modprobe $DRIVER. Without this, cpuspeed will never work on my systems. Does it work elsewhere?

cpuspeed does work for powernow enabled AMD machines.

I don't disagree with any of your posts ... however, we will continue to publish these RPMS exactly as they are released upstream.

I personally recommend that read ahead and read ahead early is turned off ... and also cpuspeed unless you have a laptop and it works for you.