Re: multi CPU's
On Thu, Apr 06, 2000 at 07:28:06AM +0300, Eray Ozkural wrote:
> Tom Rothamel wrote:
> > It probably wouldn't be all that useful in this case, since the kernel
> > image is essentially completly different. Multiple kernel images or
> > packages seems the way to go.
> >
>
> Is it totally different? That was my implicit question. Don't you
> think there should be only a marginal difference between the two
> images, since saying SMP just switches a few preprocessor symbols
> here and there. Then, the bulk of the binary code would be same.
Nope. SMP is a pretty hefty change. A lot of low level Linux code is
inlined. The spin locks differ a lot between UP and SMP, they are
mostly no-ops on UP and the full asm sequence in SMP, same for the
spin lock structures which have all the data in SMP and have zero
length on UP (or one int length for gcc 2.7.2.3).
That means a) SMP kernels have a lot of additional asm spread over the
kernel and b) every code that accesses a structure that contains a
spinlock structure could have to use different offsets to access a
field on UP and SMP. Because of b) you should also never try to force
loading of SMP modules on UP and vice versa, it might get you memory
corruption[1].
> Though I'm pretty sure those preprocessor symbols are then scattered
> all over the megs of source code. But that seems to be less than 1000.
> [I've checked].
That's the Linux design philosophy. Put the necessary #ifdefs into
header files to define macros which to avoid #ifdefs in the actual C
files. That means that your count is multiplied by the count of each
macro use.
[1] Modules must always be compiled with the same compiler and kernel
options as the kernel used. Otherwise you really ask for
problems. Don't install separately downloaded binary modules.
--
Andreas E. Bombe <andreas.bombe@munich.netsurf.de> DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/
Reply to: