lkml.org 
[lkml]   [1997]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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"

\
 
 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans