On Wed, Jun 21, 2000 at 12:49:03PM +0200, Chen Shapira wrote:
> Nothing in the concept of MK has inherent inefficiency.
I tend to think that the lack of trust and the lack of shared
structures between layers inherent in all the mk oses structures have
a non-compressible cost.
The lack of trust means that a process checks the integrity of every
parameter when it gets a command message. This is good for stability,
potentially, but this has a cost. While the tests in a monolithic
kernel tend to be minimalistic, only checking user-provided parameters
or whatever can be checked _quickly_. But there is still a lot of
trust, and hence a lot of unchecked parameters and pointers, between
the different subsystems of the kernel.
The lack of shared structures increases a lot the number of lookups.
For instance, imagine you try to read from a file descriptor. Under,
say, linux, the fd is passed to the kernel as a number. The kernel
lookups a File * from this number once. This File * includes
everything you may need afterwards: pointers to the inode, to the
filesystem routines to use, to the partition, the device, etc... On
the other hand, on Hurd, you have first an in-glibc lookup from fd to
hurd_fd *, which contains a mach_port_t (a number) that the kernel
uses to lookup for the ext2fs waiting thread, which has of mach_port_t
of the device which the kernel uses (etc...). I guess you got the
point. Factor in all the locking that has to go with it (which tends
to be avoided on monolithic kernels thru reference counters) and the
cost raises quickly.
Of course, the Hurd is far from having to bother with that. The
number of layers of junk that have to be removed before a decent
performance can be reached is already impressive[1], and in front of
that these previous problems are second order (or third).
OG.
[1] Try to follow pread() and cry.
