Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!sdcsvax!mod-os
From: mod-os@sdcsvax.uucp
Newsgroups: mod.os
Subject: Re: User-state file servers versus kernel implementation
Message-ID: <2464@sdcsvax.UCSD.EDU>
Date: Wed, 14-Jan-87 14:38:03 EST
Article-I.D.: sdcsvax.2464
Posted: Wed Jan 14 14:38:03 1987
Date-Received: Thu, 15-Jan-87 03:10:17 EST
References: <2458@sdcsvax.UCSD.EDU>
Sender: darrell@sdcsvax.UCSD.EDU
Reply-To: wegrzyn@cdx39.UUCP (Chuck Wegrzyn)
Organization: Codex Corp, a division of Motorola; Canton, MA, USA
Lines: 51
Approved: mod-os@sdcsvax.uucp

--

  In a distributed system that I am working on at the moment I built servers
to run as "user-state" servers. These servers ran as 'high priority' user
processes - they went through the 'real time scheduler' and were guaranteed
to run before 'normal' user processes. Overall, I would say, the experiment
was a failure, and not for the obvious reasons. It had to do with performance.

  I later modified by servers to be autonomous entities that ran inside the
Kernel's address space. When I did this performance picked right up. What
was happening in the original implementation was do singly to virtual memory
cache and TLB flushing and page faulting. When I made the server run inside
the Kernel address space, I didn't need to flush the VM cache, the TLB and I
didn't get page faults (at least not as frequently).

  While I still believe that a system should be written with a kernel and
surrounded by servers, I think it is advisable to make the point that some
servers need special handling. The current system I have supports two types
of servers - normal and high-performance. Based on the type of server, the
system does different things; this only makes the system slightly more 
complicated. Note that this only applies to systems with virtual memory; in
systems without virtual support I would expect no difference in performance.

  The two biggest reasons for constructing the system with a small kernel and
surrounded with servers was portability and maintanence. The only part of
the system that needs to be adapted to the new environment is the kernel - the
servers stay the same. The other reason, maintanence, was also important - the
system can change and I didn't have to worry about wierd (and forgotten) 
side effects : the interface is straight forward.

  A note of interest is that the file server I have written is machine
independent - a disk created and built on one machine can be read and accessed
on another (the 'endian of the machine doesn't matter). What I have found is
that performance is hindered too much ( < 0.5% of the processor time is taken
accounting for the rigid data format). Thus, assuming the physical media is
the same, I have taken disks formatted on an IBM PC and used them in the
disk drive on a National Semiconductor box without problem.

  Another interesting point is that I have separated the directory from the
file system. The directory is nothing more that a database server with a
few extensions (it is a B+ tree). What I am able to do is store not only
file names (and file server information), but things about processes, etc.
This turned out to be useful - I save .login style things in the database, 
etc.






--