[lkml]   [1997]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    "love without fear"

     \ /
      Last update: 2005-03-22 13:40    [W:0.018 / U:13.476 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site