CentOS - Jul 2006 - Kernel-utils stupidities (readahead and cpuspeed)

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?

Yours
-S
--
Simen Thoresen, Dolphin ICS

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! :-)

-- 
Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.centos.org/pipermail/centos/attachments/20060710/2334550d/attachment-0002.sig>

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>
We do seem to have this in CentOS-4.3
> 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.
2.6.9-34.0.1 for CentOS-4.3
> <snip>
> -S
> --
> Simen Thoresen, Dolphin ICS
> <snip sig stuff>

-- 
Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.centos.org/pipermail/centos/attachments/20060710/bdb83a36/attachment-0002.sig>

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.centos.org/pipermail/centos/attachments/20060712/ef8a67a0/attachment-0002.sig>