Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!rochester!pt.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
From: Richard.Draves@CS.CMU.EDU
Newsgroups: comp.os.mach
Subject: Re: Mach performance? [Long]
Message-ID: <oZZauai00hYP91GFUm@cs.cmu.edu>
Date: 25 Dec 89 19:01:58 GMT
References: <cZYIzoW00jdX4CVWFY@cs.cmu.edu> <QZYJhvu00hYP4Qa1N2@cs.cmu.edu>,
	<PCG.89Dec23140426@rupert.cs.aber.ac.uk>
Sender: rpd@M.GP.CS.CMU.EDU
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 26
In-Reply-To: <PCG.89Dec23140426@rupert.cs.aber.ac.uk>

Excerpts from netnews.comp.os.mach: 23-Dec-89 Re: Mach performance?
[Long] Piercarlo Grandi@rupert. (7140)

> It is quite possible and actually I think (I did
> not actually do it) fairly easy to move the netmsgserver in the
> kernel, so that context switch time is essentially nullified.

I wouldn't want to move the netmsgserver into the Mach kernel.  The
netmsgserver is a pretty hefty program.  As Rick mentioned, it can
handle multiple network protocols.  It has security capabilities, to
protect port rights.  (See Robert Sansom's thesis.)  It is the
base-level name server.  (Once two parties on different machines have
exchanged send rights, they can transmit more port rights back and
forth, but the netmsgserver has to be involved in the initial bootstrap
that sets up the first remote send right.)  It reformats data in
messages (like fixing byte order), according to the type descriptors in
the message and the hardware architectures involved.

The "short-circuit" experiment did demonstrate that it is feasible to
avoid the netmsgserver on performance-critical paths.  I think this is
much more palatable than moving the entire netmsgserver into the kernel,
although it does compromise the Mach IPC model to some extent. 
(Theoretically, the netmsgserver is just another user task and doesn't
need any special kernel support.)

Rich