One of the easiest (read, cheapest) ways to improve hardware performance is
to put more than one CPU on the board. This can be done either making the
different CPUs take on different jobs (asymmetrical multi-processing) or by
making them all run in parallel, doing the same job (symmetrical
multi-processing, a.k.a. SMP). Doing asymmetrical multi-processing
requires specialized knowledge about the tasks the computer should do, which
is unavailable in a general purpose operating system such as Linux. On the
other hand, symmetrical multi-processing is relatively easy to implement.
By relatively easy, I mean exactly that -- not that it's really
easy. In a symmetrical multi-processing environment, the CPUs share the
same memory, and as a result code running in one CPU can affect the memory
used by another. You can no longer be certain that a variable you've set to
a certain value in the previous line still has that value -- the other
CPU might have played with it while you weren't looking. Obviously, it's
impossible to program like this.
In the case of process programming this normally isn't an issue, because
a process will normally only run on one CPU at a time12.1. The kernel,
on the other hand, could be called by different processes running on different
In version 2.0.x, this isn't a problem because the entire kernel is in one
big spinlock. This means that if one CPU is in the kernel and another CPU
wants to get in, for example because of a system call, it has to wait until
the first CPU is done. This makes Linux SMP safe12.2, but terriably inefficient.
In version 2.2.x, several CPUs can be in the kernel at the same time. This
is something module writers need to be aware of. I got somebody to give me
access to an SMP box, so hopefully the next version of this book will
include more information.