Messages in this thread | | | Date | Tue, 9 Sep 1997 11:31:32 -0500 | From | Michael Elizabeth Chastain <> | Subject | Re: CONFIG_SMP patch available for 2.1.54 |
| |
Bill Hawes asks:
> I've been puzzled for a while with the discussion of __SMP__ and > CONFIG_SMP. Do some uni-processor machines have a problem with SMP > kernels? I've been running mine (P133, 32M, ASUS P55T2P4 MB, EIDE HD) > with SMP-compiled kernels for months without problems.
Mine does. I have an IBM SLC/486-33. Uniprocessor 2.1.54 works fine, but SMP 2.1.54 gives me an unlimited number of "lock from interrupt context at %p\n" messages. I don't mind because I don't expect 486 SMP to work anyways. (But this did prevent me from testing my CONFIG_SMP patch very well).
> 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.
Personally I would like to get rid of about half these tests and just go with the fractionally slower code with no configuration tests. I don't mind having arch/i386/kernel/smp.c linked in or not depending on __SMP__, but I don't like seeing __SMP__ in the middle of low-level include files. Besides the code cleanup benefit, it would eliminate the distinction between SMP and non-SMP modules.
But that's just my opinion.
Michael Chastain <mailto:mec@shout.net> "love without fear"
| |