l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: L4-hurd discuss


From: Marcus Brinkmann
Subject: Re: L4-hurd discuss
Date: Sat, 25 Jun 2005 23:15:26 +0200
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 22 Jun 2005 14:19:46 -0300 (ART),
Fortes Marcelo <address@hidden> wrote:

[performance of multi-server operating systems]
 
> > Well, it's an open question.  It's true that there
> > is some overhead,
> 
> So lets talk about this question.

Hey, we do all the time ;)
 
> > 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.
> 
> And how can it be solved? By L4? i think not.

See Espen's response.  The L4 group has shown that there is an
incredibly amount of optimizations that you can do even on suboptimal
hardware.
 
> > 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.
> 
> Now you touched in a point i was wondering for a time,
> does have you on mind that some servers can not run on
> top of L4?

No, in my mind all the servers I want to run on L4 will run on L4, and
there will only be the minimum required overhead.  Well, the latter is
something we have to work on.

This does not mean that we can just make up _one_ way to implement a
certain server and expect this to work well.  We will have to be
creative and change the way things are designed.  For example, one
change I am currently in the process of going through is to remove all
blocking RPCs from the design, like a pipe read() or a select().  By
replacing this with a notification system and continuations, we can
optimize non-blocking RPCs fully and only penalize blocking RPCs (by
splitting them up into multiple RPCs).
 
> or even try to imagine the follow situation.
> 
> In a teoric vision way a multi server system have more
> flexibility as you can debug a server in user space,
> shutdown it and restart without affect the rest of
> sytem but only if servers have not a particular
> interdependence between they and particular processes
> being executed at the same time.

I don't think that is a reasonable goal for us to pursue.  We will
have a set of system services which can not be shutdown and/or
replaced without affecting the rest of the system.  It's not that we
can't do it in principle, it's just not part of our goal set.

> as maybe for exemple if maybe HURD Proc or Exec or
> File System or Memory Mananger servers was shutdowned.
> 
> So to avoid IPC Overhead for exemple could crytical
> servers as Auth, Proc and Exec run as a single server
> just as objects inside it? 

You could, but I am doubtful if this would help a lot.  It's our
opinion that such steps backwards are not necessary, unless you go all
the way and have a monolithical kernel.

> it means that you have less servers running on top of
> L4. Have you plans about of it?

Yes, we have plans.  Our plan is to have more servers, not less ;)
 
Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]