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: Marcus Brinkmann
Subject: Re: The Hurd: what is it?
Date: Thu, 10 Nov 2005 00:27:08 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

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?  The numbers are really staggering.  We do know
that more people don't mean better work, due to communication overhead
etc (mythical man month).  So, there were most certainly project
management failures.  But I think the papers make very clear that this
was not the sole reason for the failure.
 
> > 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.

> 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.

> 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.
 

[active translators]

> Then this is something that we can solve by extending our current
> implementation, isn't it? (maybe not with the world's best solution, but
> with a working one :-)

Maybe.  But I have no good ideas how to do it incrementally.
 
> > > > If you are looking at the actual Hurd implementation, you can find
> > > > plenty of denial of service attack possibilities, as well as denial of
> > > > resource attack possibilites.  No need to even try to enumerate them
> > > > all.  Note the absence of a quota system.  Note the absence of
> > > > feasibility to implement a quota system in such a multi-server system,
> > > > without some ground-breaking architectural changes.
> > > >
> > > 
> > > 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.

As for migrating threads, I don't have any further comments right now.
The issue deserves more attention than I can give to it at this moment.

Thanks,
Marcus






reply via email to

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