On Fri, 13 Nov 1998, Mark Hahn wrote:
> 2.0 kernels have known, inherent problems with SMP,
> but 2 processors should be stable. of course, there has never
> been, nor will there ever possibly be any clock-related instability.
If the kernels all worked perfectly it would be true, but they don't so
it's not. When clock speed cranks up to the next level, it has in the
past and will probably in the future expose sloppy or kernel-obsoleted
programming in e.g. device drivers and the like that made "safe"
presumptions about some key latency or locking mechanism -- a few years
ago -- that are suddenly no longer approximately true. If you like, a
higher clock speed automatically ups the ante in "stress tests" of
kernel stability.
A glance at the list archives over the last few years will clearly show
that this occurred, for example, with network drivers on SMP systems as
CPU's passed the 200 MHz level. The chronic problems of pre-2.0.32
kernels with SMP deadlocks were also in many cases related to speed -- a
slowish system would do just fine, where a faster system would have a
much higher chance of hitting the unstable parts of the operating system
in the (small) window of opportunity for a deadlock. I think that the
same thing occurs (or did occur) even more frequently in 2.1.x kernels,
as it is a development kernel and by hypothesis has had more bugs in it
to be exposed in this way.
I always brace myself when putting linux (or, in the old days, anything
else) on the latest/newest clock version of a CPU. Sometimes it works
just fine, other times there is a flurry of list activity or calls to
the OS vendor as a new kernel bug that was rare and nearly occult
becomes common enough to become troublesome (and maybe even squash).
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
