Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucsd!sdcsvax!darrell
From: mason@polya.stanford.edu (Tony Mason)
Newsgroups: comp.os.research
Subject: Kernel Size (Was: Re: Wisdom, a pedantically named operating system)
Message-ID: <4702@sdcsvax.UCSD.EDU>
Date: 3 Mar 88 16:35:04 GMT
Sender: darrell@sdcsvax.UCSD.EDU
Organization: Stanford University
Lines: 50
Approved: mod-os@sdcsvax.uucp


An interesting conjecture, that a small kernel equates with low efficiency,
and a large kernel equates with high efficiency.  From what I've seen of the
performance figures, this isn't truly supported.  For example, in V, the
kernel is "small" - 110-120K.  Yes, we have lots of user level processes -
on my workstation I'm running (in addition to the kernel) an interfaceserver,
which controls keyboard/mouse input, a sun120display process which controls
the screen, an execserver, which controlls all execution requests.  As well,
there is an exception server which handles faults on the processes running
on my workstation.

So, I too have 500K-800K of "system" type processes.  So what is the
difference?  Well, lets try this one on:  I'm working on the executive
server.  I want to start up a new one.  Well, in your huge kernel system I
reboot.  On mine, I have a program that I call which tells the executive
server to directly execute a new server.  Hence, in 5-10 seconds I can change
something for which you would still be trying to shut down.

Or display servers.  Or internet servers.  Why should I be required to have
all the tcp/ip code *inside* my kernel?  If it is in a separate process and I
don't want to use a telnet or ftp connection, I save that much space.

Then, there is one other significant advantage.  As any project becomes
large, it becomes more complex and difficult to maintain.  With a small
kernel it is easy to change, recompile and rerun.  I know.  I've worked on
both the V kernel and the Unix kernel.  I can rebuild a Unix kernel about
once per hour.  I can rebuild the V kernel about twice per hour. 

In our group, we can offer you virtually everything you can get under more
conventional "large kernel" operating systems.  Including solid portability.
We use two SUN systems for file server access.  We can shut down the file
systems, check them, and all the while the other resources those machines
offer are still available to the entire world.

Recently, we have been updating our work to use a new version of our internal
transport level protocol (VMTP --- c.f. RFC 1045.)   I've been working on the
Unix stuff for a month now.  I'm just starting to get something useful.  The
V system was modified over a period of a week to implement several levels of
changes.

Certainly, the tendency is for an O.S. to start small and grow larger as the
number of services it must offer grows.  Just because some are further down
that path, doesn't imply that path is the only, or best, path to follow.

Tony Mason
Distributed Systems Group
Stanford University
mason@pescadero.stanford.edu

P.S.  In the time I wrote this note I completely rebuilt, from scratch, the V
kernel.  Try that with UNIX.  A complete rebuild on my microvax takes hours.