(no subject)

   Date: Fri, 25 Feb 1994 14:31:50 +0100
   To: Andrew Valencia <vandys@cisco.com>
   cc: vsta list <vsta@cisco.com>
   From: Werner Vogels <werner@freya.inesc.pt>
   
   2. distribution.
   
   Support for distribution is essential. And treating it as an "add-on" feature
   may turn out to be a fundamental mistake. As a good micro-kernel should do
   VSTa leaves it all to the user space to implement things, but until now we
   have had not so very good experiences with user level implementations of
   protocols stacks. Although Chris Maeda's work was great he still arrived
   at times comparable to monolithic Mach and Ultrix. And we also know by now
   that the way the packet filter/demultiplexer is build and is able to
   interact with the device is crucial to get the better performance. As is the
   quest to avoid crossing protection domains while moving the message through
   the protocols. [Maybe you can comment on this Chris? as it is more your cup
   of tea].

Well, no one ever said microkernels could get better performance than
monolithic kernels. Microkernels are supposed to give you a more
flexible system. We're still trying to figure out if that flexibility
can be delivered with an acceptable performance cost. Right now, the
answer is maybe. We know one way to do it for networking; for my
thesis, I'm trying to determine if the approach I used for networking
will work in general.

There are a couple things that might help I/O performance. As you
mention, one is a mechanism to transfer data across protection
boundaries. A lightweight mechanim to transfer control would also be
useful. Two papers to read for ideas are Peter Druschel's 1993 SOSP
paper on fbufs (ftp from cs.arizona.edu:/xkernel/fbufs.ps) and Brian
Bershad's work on Lightweight RPC (in ACM Transactions on Computer
Systems, sometime in 1990, 1991, or 1992). Quick LPC in Windows NT is
actually an implementation of Bershad's LRPC ideas. Another useful
mechanism would be a way to quickly call interrupt handlers in user
space.

(You might have already examined some of these issues in vsta; I
haven't had a chance to do much with the system lately.)

By the way, thanks for the compliment.

   We could also learn from Mach what not to do if you want to extended you
   port & port capability space across a cluster of machines.

A good place to start is the network IPC work at Arizona
(cs.arizona.edu:/xkernel/usenix93.ps). The implemented Mach IPC in
the xkernel and talk about some hard parts encountered when
implementing the mach port semantics in a distributed environment.

The fundamental problem with Mach IPC is that it violates Butler
Lampson's rule of thumb that you shouldn't treat the local and remote
case the same in a distributed system. A reasonable solution for IPC
might be LRPC in the local case, and some kind of location-transparent
network IPC in the remote case. V and Amoeba are possible sources of
inspiration for the latter.

Regards,
Chris Maeda
Received on Sat Feb 26 16:09:40 1994