l4-hurd
[Top][All Lists]
Advanced

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

Re: Questions


From: Martin Schaffner
Subject: Re: Questions
Date: Tue, 28 Oct 2003 18:57:30 +0100 (MET)

Neils Möller wrote:
> The point of L4 is that ipc is highly optimized, the L4 experts will
> have to correct me if I'm wrong but I think it's about 100-300 cycles,
> and then thers'a also a cost of invalidation of CPU and MMU caches,
> where the small l4 footprint is good at least for CPU caches (I'm not
> familiar enough with memory management to say anything about MMU
> state). The cost of one context sitch could well be an order of
> magnitude cheaper than in linux.

Does that mean that syscalls are also potentially a magnitude cheaper
(assuming the syscall doesn't have to do much)?

Marcus Brinkmann wrote:
> There are two issues.  The first is how L4 implements IPC.  The second is
> how the Hurd uses IPC.  The L4 IPC mechanism is very fast.  It does not
copy
> the message twice, it copies it directly from the source TCB to the
> destination TCB.

TCB == task control block ?

> Of course, you _have_ to switch the context eventually to the server,
which
> then processes the RPC, and then you have to switch back.  This can
> be a problem, but probably cache pollution and TLB flushing is a bigger
> problem than the actual context switch

TLB == translation lookaside buffer ?

> No, no.  For any IPC you make a system call to the kernel.  Even for local
> IPC within a process, and definitely between processes.

Too bad :-(

>>which in turn RPCs
>>the driver of the backing store (will probably reside in ring 0) for the
data.
> 
> Yes.  In fact, there will probably another task inbetween the driver and
the
> server.

Which task would that be?

>>Does this mean that the Linux Userland Filesystem
>>(http://lufs.sourceforge.net/lufs/intro.html) poses security risks?
> 
> I don't know lufs, so you are the judge.

Unfortunately, I don't know it either :-)
A friend pointed me to it, saying that the hurd won't be necessary since you
can have user-filesystems on linux, too!
I also think it would be better to have this feature designed into the
system from ground up. I look forward to trying hurd/l4 out. Unfortunately, I'm
not well-versed enough in system-level programming to be a big help for coding,
all I can do at the moment is to point out comma-mistakes in the doc ;-)

> For the first question, can users install lufs without the system
> administrators help?

Certainly not, but he can't install the hurd without root access either! :)
I don't know  the answer to the other questions...


I have an idea for optimizing the hurd, don't know what it's worth:

Make a build option to assemble all always-used servers into one process.
The servers, by design processes, would be just threads with this option. This
option would effectively turn the hurd into a monoserver. The disadvantage
would be, of course, that each server thread could take down the system, but if
we only include servers which we (have to) trust anyway, like the root fs,
the hard disk driver, and other essential servers, a crash would render the
system unusable anyway. The advantage would be that IPC between servers would
be able to be super-fast (according to my understanding). The other advantages
of the hurd (flexibility, easier development of new filesystems/drivers and
their not bringing down the whole system) would be retained.

Thanks,
Martin

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++





reply via email to

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