bug-hurd
[Top][All Lists]
Advanced

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

Re: The Hurd: what is it?


From: Sergio Lopez
Subject: Re: The Hurd: what is it?
Date: Thu, 10 Nov 2005 01:35:54 +0100

El jue, 10-11-2005 a las 00:27 +0100, Marcus Brinkmann escribió:
> At Wed, 09 Nov 2005 23:22:33 +0100,
> Sergio Lopez <koro@sinrega.org> wrote:
> > 
> > El mié, 09-11-2005 a las 20:32 +0100, Marcus Brinkmann escribió:
> > 
> > We don't know (since the papers are not so technical, and we can't look
> > into the code) in deep what they do to Mach or how they implemented the
> > servers. We just know that they changed Mach in many ways (IPC
> > synchronous in a unknown way, user-space device drivers...) and that
> > they implemented their servers with other prorities in mind than ours.
> > 
> > And if Workplace works about 3 times slower than OS/2, they must did
> > something wrong, since that's more or less the rate of slowness for Hurd
> > vs. Linux with an unoptimized, asynchronous IPC ;-)
> 
> I don't disagree with any of what you say, but please consider that
> they had:
> 
> 400 microkernel programmers
> 1500 OS/2 programmer
> 2 billion dollar
> 
> to spend on this project.  I like to believe that we work more
> efficiently than a big corporation like IBM, but do we work _that_
> much more efficiently?  

Of course! Heh, just kidding :-) Now seriously. I don't know why IBM
failed to archieve his purpose. I know that we have a system that
_works_, but doesn't do it with a reasonable performance. And we know
how to improve it investing a relative small amount of work. It's worth
trying, isn't it? ;-)

> > > The Liedtke papers shed a light on why this is so.  The problem is not
> > > purely the IPC performance.  A big issue is cache consumption: If the
> > > kernel's working set is bigger than the cache, there is a strange
> > > effect: Performance degrades as you increase the cache size!  This is
> > > because the kernel is eating the cache, and it needs to be refilled.
> > > This is why microkernels must be small, as in actual number of bytes.
> > > 
> > 
> > Having a small microkernel in number of bytes is just one way to
> > archieve a small working set, but not the only one.
> 
> This is true, but unless you propose a way, I would say it is the only
> way we know that works :)
> 
> Note that some version of L4 consumed 4 TLB entries for one IPC: 2
> that were the same for every kernel interrupt.  1 for the source
> thread.  1 for the destination thread.  It is hard to do better than
> that.  And even L4 with all their sophisticated design just _barely_
> manages to run L4Linux with competitive performance to plain Linux.
> 
> This means to me that these optimizations are mandatory, not optional.
> 

IMHO the TLB issue is pretty controversial. Even having a heavily
optimized kernel like L4, you must also take care that the servers are
also constructed with a similar fine-grained fashion (which is pretty
hard from the extensibility point of view), or all the magic of the
microkernel will be for nothing.

That's not surprising at all since (IMHO again) it's more a hardware
architecture problem than a software one.

On the other hand, I don't think that beating in performance to others
systems is an objetive for the Hurd, but being extensible with a
reasonable performance.

> > Probably will be
> > interesting to research this kind of this fine-grained optimization at
> > some point,
> 
> Well, the research has already happened, and the results are
> available, and very clear.
> 

I mean research on the current Mach's codebase.

> > but I don't see it as a priority and I don't think that this
> > is the main reason for Mach IPC slowness.
> 
> It's one thing to say this is not a priority for you.  That's OK.  But
> if you think that the papers don't accurately attribute the main
> reason for Mach IPC slowness, then that is a surprising claim, and I
> know a lot of people (including me) who will be interested to learn
> more about what you know that we don't know.
>  

I've never said that the papers are wrong. As you surely know, for the
Mach's case many papers (I don't have time right now to give references,
I can put them tomorrow if you want) point to the cost of context switch
(including dealing with the scheduler), message buffering/enqueueing,
message header processing and data copying as the main reason for IPC
slowness. This doesn't mean that the cache issue can't _also_ be a
problem, just mean that there're other problems that we know how to fix
them.

> > > > Mach knows about almost every resource allocation that the servers do, 
> > > > so I
> > > > don't think that will be extremly hard to solve this without completly 
> > > > breaking our current design.
> > > 
> > > Mach doesn't know on whose behalf the server does the allocation.
> > >   
> > 
> > Yes, but it knows about the server and the resource. We can take this as
> > a primitive.
> 
> I don't understand what that last sentence means.  Are you saying that
> you think it suffices to attribute the resources to the server?  This
> is exactly the wrong thing to do.
> 

I mean that using this, you could construct an interface for this
purpouse (I'm just guessing, I don't know enough about this issue to
give a complete answer--I need to work on this).
-- 
Sergio Lopez
koro@sinrega.org





reply via email to

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