[linux-elitists] ME roadshow

Eugene Leitl eugene.leitl@lrz.uni-muenchen.de
Thu Aug 31 10:02:35 PDT 2000


Greg KH writes:

 > Linux has not ever professed to be "realtime" (and let's not digress
 > into what the meaning of 'realtime' is...)
 
I think Linux has a very good potential to be eventually mutated into
a go-anywhere solution, ranging from tiny-footprint to the largest
legacy dinosaurs. We need a small-footprint nanokernel with Linux
personality wrapper (purists would argue that this has nothing
whatsoever to do with true spirit of the Tux, I beg to disagree),
which can do small-footprint, realtime, high-availability,
high-reliability computing.

But we must want to do it. Orelse there will be niches where the
penguin will never reach, which would not be a good thing. I would
like to be able to use the same nanokernel functionality on a DSP
cluster, a PC or a big blue mainframe.
 
Of course I'd rather have an array of dedicated Forth hardware, but as
I already mentioned, in absence of desktop nanolitho printers this is
an expensive (or slow, in 60 MHz FPGA emulations) way of doing
computing.

 > What is the problem with RTLinux?  It is a great solution for running a
 > Linux kernel on a processor for an application that needs better latency
 > than normal Linux can provide (or better latency than NT, or Win95.)
 
RTLinux is window-dressing (in fact a small realtime nucleus
dispatching calls, very much like a nanokernel). Let's remove the
cause, instead of doctoring with the symptoms.
 
 > For the application you are speaking of (huge arrays of CPUs doing
 > nothing but passing messages around) Linux is not the solution.
 
Doing nothing? I've never said these things are doing nothing. And, as
it happens, all modern supercomputing is cluster-based (SGI is with
their shared-memory monsters is about to bite the dust), and with the
exception of certain infinitesimal niches (QCDSP) Linux/Tru64 are the
only contestants. 6 kNode clusters are not unprecedented, and the
trend goes into millions (pFlop Blue Gene with over a million
processors is supposed to be up by 2004), multibillions with
nanotechnology (I expect the first molecular memories in 10-15 years,
cellular automaton hardware (a kind of super-FPGA) soon after).

 > But I don't think that a hand-coded in assembly kernel is a solution
 > either.  The code churned out by todays C compilers is much better than

Nowadays assembler undeservedly has a bad rap. I think the nanokernel
and certain numerical libraries have excellent uses for handcrafted
assembly, provided it is being done by true wizards. I have the
master's thesis of Yann Guidon with handcrafted lattice gas MMX for
computational fluid dynamics, which absolutely kicks butt.

 > the "average" assembly programmer can create.  And when you have to
 > maintain that kernel over time... well I have been there, let's just say
 > that I would never do that again in my lifetime.
 
The point of a nanokernel is that it is small enough not to contain
significant number of errors. We're talking about 2 kLoC, not 200
kLoC.  You design that tiny piece of code really really carefully and
debug it to death before releasing it. Afterwards it will only require
minor bug fixes (have you heard of people doing major debugging of an
OS VM?).

 > Ah, but message passing kernels (or microkernels) have the disadvantage
 > of the fact that all they end up doing well is passing messages very
 > quickly, not getting any "real work" done.  But I don't know anything

Actually, (minimal) message passing should be done purely in
hardware. Ideally, you #define your stuff, which either translates
into a nanokernel (or a userland library, see M-VIA) call or a CPU
instruction.

 > about how the OSs work on those 100+ CPU clusters done by Intel and IBM.

You should read the Beowulf archives. You should really read the
Beowulf archives.

 > That is a whole arena that is outside of my current knowledge (hell, I
 > just _finally_ got access to a 2 proc machine for the first time in my
 > life on Monday.)

SMP is a very different beast from a cluster.

 > Can anyone point me to some links about the OSs in these superscaler
 > clusters?
 
Try http://supercomputer.org , they've got the searchable Beowulf
archives there. Also try beowulf-underground.org , and beowulf.org

 > OB Linux elitism:
 >   Linux has prospered over a whole lot of other microkernel OSs due to
 >   the advantage of it's monolithic kernel.  There is plenty of
 >   documentation out there proving that for single processors,
 >   microkernels is _not_ the way to go.
 
I've heard opposite things. It depends on the implementation. And I'm
not talking about microkernels, the 500 kByte Mach is (purportedly) a
microkernel. I'm talking about about a minimal veneer of software on
top of bare silicon.




More information about the linux-elitists mailing list