Re: lilo vs other OS bootloaders was: FreeBSD makes progress

From: Helge Hafting (helgehaf@idb.hist.no)
Date: Wed Sep 05 2001 - 03:03:03 EST


"Grover, Andrew" wrote:
>
> > > ANdreas Dilger wrote:
> > > > Win2K even abstracts all SMP/UP code into a module (the
> > HAL) and loads this
> > > > at boot, thus using the same kernel for both.
> >
> > > the only possibility of this shows how ugly is SMP in win2k...
> >
> > Not necessarily. More likely the difference between SMP and
> > UP is marketing-only and both have the overhead of SMP
> > locking, etc..
>
> No, they don't do this by running an SMP kernel on UP, they do it by
> abstracting functions that care about SMP into another module.
>
> Here's Linux:
>
> Drivers (SMP agnostic)
> Kernel (SMP/UP specific)
>
Linux modules are not agnostic, they too are SMP specific.
Because a module may use spinlocks.

Modules should really be compiled with the kernel. They are an
intersting way to save some memory, they are not a way of
distributing drivers or anything like that.

> I'm not advocating anything similar for Linux, I'm just saying it's an
> interesting thought experiment - what if the SMP-ness of a machine was
> abstracted from the kernel proper? How much of the kernel really cares, or
> really *should* care about SMP/UP?
>
> For one thing, it would get rid of the hundreds of "#ifdef CONFIG_SMP"s in
> the kernel. ;-)

You would also get rid of performance. The agnostic kernel would be
slower than simply running the SMP kernel on UP.

Here's why:
You can easily make an "agnostic kernel & modules" by changing the
spinlocks to function calls. Then you'll provide a null stub call site
for running UP, and the real spinlock code for running SMP.

Unfortunately, this gives the overhead of a function call, both for SMP
and for UP. This overhead is usually _bigger_ than the overhead of a
inlined spinlock.

So if you aim for a simple distribution - go for SMP. The loss on UP is
small. I have haerd of cases when the SMP setup code fails on UP
when smp hardware is missing. You could of course work to eliminate
that.

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:30 EST