a little thing Jonathan S. Shapiro (jsshapiro@earthlink.net)
Wed, 22 Apr 1998 16:46:04 -0400

A while back I spent 2 days that turned into 2 weeks building compression support into the EROS disk bootstrap code. It was becoming clear that the install floppy would need to hold a lot of initially empty pages, and in the EROS model space for these actually has to be out there on the disk somewhere.

The (still incomplete) networking code finally pushed me over the edge. A normal PC floppy holds 2880 sectors. I've just booted a 3112 sector volume into an in-memory ramdisk.

This volume contains a kernel, the bootstrap code, and 248 object frames (each one page) on disk, populated as follows: 

	Content						Occupies
	-------						---------
	233 initially allocated nodes			34 frames
	53 initially allocated non-zero pages		53 frames
	21 initially allocated zero pages		21 frames
	balance (initially unallocated frames)		140 frames

Before I increased the volume size, it held 40 unallocated frames, which was insufficient.

This prompts me to two thoughts:

  1. I had not previously appreciated the degree to which EROS/KeyKOS applications are able to run out of "virgin" frames and therefore avoid the overhead of faulting them in. This should have significant (positive) impact on performance that I had not adequately understood.
  2. It is a surprise to me just how small applications on this system are proving to be. While the kernel is a lot bigger than I might have liked, the application-level stuff is proving to be pretty tight. Jonathan Adams recently made a similar comment.

shap