Re: GNU on OpenSolaris

[Marcus Brinkmann]

Hi,

I am happy to discuss multi-server system design with you.  I am not
interested in OpenAnything.

At Mon, 20 Jun 2005 21:21:32 -0300 (ART),
Fortes Marcelo <address@hidden> wrote:
> Mach have several performance pennalitys in his design that
> compromises a performance for an multi-server based operating
> system. Beind more indicated to a Single-server OS Design as it was
> in NeXT and MacOS - X. However in this way it does not take the real
> advantages of a micro-kernel porpose becouse it reflects another way
> of a Monolithic system becouse almost system core are exported to a
> unic bloated server... And device drivers that still being into the
> kernel.

Mach was the first attempt to make it work, and it does support
multi-server operating systems in a functional way.  IE, it has all
the required functions to make it work.  It was not meant to be used
only for single servers.  Your observation that this does not reap
much benefits from the design is right on.

There was an attempt to put device drivers out of Mach---Mach in
principle supports it.  But it was a performance desaster, and never
made it anywhere.

> By other Hand L4 trys to solve some of this problems with a radical
> design; exports device control to outside from kernel, Synchronous
> message passing a minimum of system calls to Micro Kernel, and maybe
> the most imprtant for performance a faster IPC.

Again, you are right on.  Which makes me wonder why you mentioned
OpenSolaris, as this gets us nowhere near to this goal.

> But it does not solve everything becouse AFAIK thre is yet the
> overhead in TLB, Context changig in regioster to each
> thread/server/object as i dont know as L4 solve.

Well, it's an open question.  It's true that there is some overhead,
but there are also benefits.  It's extremely hard to predict
performance of even simple software systems, and it is also extremely
hardware dependent.  For example, the cost of context switches depends
on the question if you have tagged TLBs and the number of registers.

L4 is heavily optimized.  The question is how much we need to add on
top of it to make it do the things we want it to do, and how this
affects performance in a negative way.  It remains to be seen.  We can
only find out by trying, and then analyzing, and trying again.

Furthermore, there are non-performance related benefits that may very
well outweigh the performance cost, if it is acceptably small.

Thanks,
Marcus