> > AFAIK, the kernel does a fine job of treating one processor as a special
> > case of SMP. Unless there's a problem on some architectures, why can't
> > we just do away with the Uni/SMP distinction?
>
> I believe lots of the distinction is there for improved performance on
> uniprocessor machines. For example, in include/arch-i386/atomic.h,
> the SMP version generates "lock" prefixes on some instructions and
> the uniprocessor version doesn't. Same with include/arch-i386/bitops.h.
> In include/arch-i386/delay.h, __udelay_val is set to "loops_per_sec"
> on a uniprocessor machine, and "cpu_data[smp_processor_id()].udelay_val"
> on an SMP machine.
look at asm/spinlock.h and think about it ... completely different
semantics for uniprocessor and SMP!
a spinlock enter/leave costs about 25 cycles on both P5's and P6's. Thats
too much.
Instead of the suggested 'EXPORT_SYMBOL(i_am_SMP)' solution, IMO a better
way is to implement some 'powermodule' thing, single .o file, both SMP and
UP version of all functions. Generated automagically by "make modules",
interpreted by modutils. Could even have more 'styles', eg: P5,i386
optimizations, etc. Basically a unique identifier should be built from the
compile flags? (kernel version is already there) Then modutils compares it
with the running kernel's compile flags, and chooses an 'allowed-set' of
styles.
we could even put several platforms into a single .o module file ... this
makes sense for distribution makers i guess.
hm?
-- mingo