PreviousNextIndex

Introduction


Site roadmap

Jorg suggested making this introduction into a roadmap, and I think that's an excellent idea.

First, I suggest you read this entire page. Then, in case you are looking for something specific, here is how to go around this site:

Documentation:

Performance optimization:

Problems:

Kernel patches and compilation:

You already have or want to upgrade to a 6x86MX:

VSPM:

Some good reasons for reading these pages

As of Linux kernel 2.0.31, Cyrix/IBM 6x86(L) CPUs are not correctly identified and setup during boot time. For compatibility reasons, Cyrix decided to make the 6x86(L) CPU emulate an 'unknown' revision 486 CPU after a hardware reset, unless special instruction sequences are executed and specific flags are enabled to permit the correct identification of the Cyrix CPU. On the other hand, the 6x86MX CPU identifies itself as a Pentium Pro!

This can be easily recognized by checking /proc/cpuinfo (for example, by typing cat /proc/cpuinfo) on a Cyrix/IBM 6x86 machine: the cpu will show as an unknown type 486.

On my IBM 6x86L PR166+ machine executing Linux kernel version 2.0.29 (without patches), cat /proc/cpuinfo will echo:

processor
cpu
model
vendor_id
stepping
fdiv_bug
hlt_bug
fpu
fpu_exception
cpuid
wp
flags
bogomips

: 0
: 486
: unknown
: unknown
: unknown
: no
: no
: yes
: yes
: no
: yes
:
: 133.12

So, the Linux kernel is clearly missing a feature: it does not correctly identify the Cyrix/IBM 6x86 (or AMD K5/K6) CPUs. Why is that so important? Well, some steppings of the Cyrix/IBM CPUs are better than others: older CPUs tend to dissipate more heat and may not behave correctly under some circumstances. Knowing what kind of CPU one has under the hood is important: one always feels better knowing that the CPU is adequately cooled and supported by the motherboard/BIOS combination.

Note that 6x86 CPUs have a bogomips rating approximately equal to the CPU core clock rate (the 6x86 PR166+ runs at 2 x 66 = 133 MHz).

The next step after correct identification of the CPU is configuration of the special features of the Cyrix/IBM 6x86 line of CPUs, the most important one being the power-down mode when executing the HALT instruction. When halted, the Cyrix/IBM 6x86 CPU will dissipate approximately 1/70th its rated operating current - if the special power-down flag is set! This not only saves trees, it will also put a much lesser load on the voltage regulator on the motherboard, which usually has a small heatsink and is not directly ventilated. In any computer system, less heat means less failures and a longer life for electrolytic capacitors, and the special power-down mode does not impose any speed penalty on Linux.

Cyrix/IBM 6x86 CPUs allow many other registers to be configured in order to improve system performance.

It is however my opinion that such fine tuning should not be included in the Linux kernel: it can easily be done with graphical tools or with an rc script during boot time (see Utilities page).

I would suggest that the kernel should not be patched at all: all CPU type reporting code and fine tuning should be done with runtime utilities. This avoids having to recompile the kernel to change parameters, and also avoids cluttering the Linux kernel source. Remeber how many times you already downloaded the Linux kernel source? You don't want to make it any larger, do you? The Cyrix 6x86 is not a different architecture after all, so the extra kernel source code is not justified. On the other hand, a good-looking utility that will allow CPU identification and performance tuning at runtime is clearly a Good Idea (tm).

However, there is a feature of the 6x86(L) CPU that cannot be enabled after boot time, it has to be specifically compiled in the Linux kernel: the Variable-Size Paging Mechanism (VSPM).

In the long term (kernel 2.0.32+?), the ideal solution would be to have a _M6X86 configuration option for the Linux kernel that would automatically compile and boot the kernel for nearly optimum performance with 6x86 CPUs. A run-time utility like set6x86 would then allow some fine tuning of the ARRs (ARRs have to be setup individually for each system, because they depend on video frame buffer address among other things).


PreviousNextIndex

Last updated on November 7, 1997.

Copyright 1997 Andrew D. Balsa