
.sh 1 Recommendation"
.pp
This section describes some of the performance enhancements which
should be implemented in KSOS-32.

.sh 2 "File System Enhancements"
.pp
Some of the planned enhancements to the KSOS-32 file system are
briefly mentioned in [KSOS85]. These and some new ideas will be
discussed here.
.lp
The desirable file system enhancements include improving the device
drivers for the disk devices, data buffering in the Kernel and
changing the organization of the on-disk structures.
.lp
The current disk device drivers handle all I/O requests on a
first-in-first-out basis. This could easily be replaced by any of the
algorithms for request ordering that have been described over the last
few years. This obviously would include seek ordering, rotational
latency calculations and block pre-fetching. In addition, KSOS-32
currently only allows one I/O request to be pending for any given
device. This is entirely a hold over from the PDP-11 version of the
system which encountered memory space limitations which prohibited the
addition of any new code to the Kernel. There is no such limitation in
KSOS-32 and changing this would give a large performance boost.
.lp
The Kernel as currently implemented does no data buffering in the
Kernel. All data is transferred to and from buffers in the user's
virtual address space. There is no caching of user data blocks. This
means that several requests for the same data block, even by the same
user, would require several physical I/O operations. This limitation
stems from the original philosphy of KSOS-11 design, wherein the UNIX
Emulator (which no longer exists) would buffer user data. Having the
Kernel buffer data blocks for both reading and writing would also gain
a large performance boost.
.lp
The on-disk structures of KSOS-32 are exactly those of KSOS-11. The
KSOS-11 file system is very similar to the Version 6 UNIX file system,
although much more robust.  However, there is still the notion of an
index area and a data block area. Because reading a file requires
accessing both the index area and the data block area, there is a
considerable amount of disk arm movement. Given the design of the
existing I/O system, this is very slow. This is almost exactly the
situation that lead Berkeley to develop the Fast File System (FFS).
KSOS-32 could essentially re-implement the FFS and gain the dramatic
improvements that this file system brought to 4.2 BSD UNIX. If a
FFS-style file system were implemented on KSOS-32, the only
differences would be a small amount of overhead (<<5%) at file open or
creation time due to some small amount of security checking.

.sh 2 "Virtual Memory Enhancements"
.pp
KSOS-32 could and should use the "copy-on-write" approach for copying
virtual address spaces during the fork operation. This would also
speed up the combined "spawn" operation. This change would provide a
dramatic performance increase. However, KSOS-32 process creations will
always be at least slightly slower because KSOS-32 process are
slightly more complex and contain more context which must be
duplicated. At best, this could lead to a less than 10% difference in
performance, compared with BSD UNIX.

