Promptness, queueing, diskless etc. etc.

[Jonathan Shapiro]

   >3. Once user data objects are not made up of atomic objects of
   >homogeneous size, the design of a backing store manager grows
   >difficult.

   In the early days, e.g. Multics, designers accepted the complexity and
   poor performance of variable size data objects (pages, file system
   blocks, main memory protection zones) as a trade off for the savings
   in real hardware.  As hardware has gotten cheaper, people have been
   willing to spend it for simplicity, and particulary for performance.


Hmm. Let me try to make that more precise.  I'm quite willing to 
restrict myself to objects composed of fixed-size units.  The
difficulty is that in the fact of heterogeneous systems these atomic
data units may not correspond directly to a unit the hardware can
protect. 

   A quick question is why you want small pages?  A system with 64K pages
   would be straight forward.  The most compelling reason for small pages
   is storage efficency, particulary with UNIX files being used as they
   are.  The case for large pages becomes more compelling as the speed of
   processors increases in relation to the speed of paging devices.

Storage efficiency is a nontrivial concern.  Another is that it may be
important to support an existing system off of existing disks that you
aren't allowed to reformat.

In my opinion, the case for large pages has nothing to do with disk
speed.  Even at 4K, the page size is substantially larger than a disk
sector.  Using software to prefetch pages in batches is much less
intrusive than changing the page size, and achieves the same
efficiency advantage at close to zero marginal cost.  Actually, if
that's the plan you want smaller pages so that the process can proceed
while the I/O is still only partially complete.

The real argument for large page sizes relates to the preciousness of
TLB entries, which is largely orthogonal to our discussion.

But the real answer is that I'm not stuck on the pages being small,
just on the reality that their size varies from machine to machine.

   One approach to mapping small pages into large slots would be to check
   if the large frame had been written beyond the extent of the small 
   page and invoke a segment keeper if it had.

This would seem to assume that the small page falls at the start of
the larger page, which it may not.  Otherwise, I agree with where you
are going here.


Jonathan