Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!homxc!dwc
From: dwc@homxc.UUCP
Newsgroups: comp.arch
Subject: Re: VM, Paging, Demand Paging
Message-ID: <1524@homxc.UUCP>
Date: Fri, 2-Oct-87 18:38:00 EDT
Article-I.D.: homxc.1524
Posted: Fri Oct  2 18:38:00 1987
Date-Received: Sun, 4-Oct-87 01:56:02 EDT
References: <8490@think.UUCP> <1745@ncr-sd.SanDiego.NCR.COM> <819@sugar.UUCP> <736@winchester.UUCP>
Organization: AT&T Bell Laboratories, Holmdel
Lines: 29

> If programs are relatively small [64K I + 64K D max]
> and if pages are relatively large (compared to size) [8K],
> then programs are likely to touch every or almost every page very quickly.
> In this case, you get better disk performance, and have simpler,
> denser kernel data structures, by swapping instead of paging.
> I.e., if working set = size of program, you might as well swap.
> 
> Note that many systems have performance domains where it is better
> to swap either entire processes, or at least, their working sets,
> in or out, rather than doing it piecemeal. Big IBM systems do this, for example.

because of the nature of disks (i.e. latency plus rotational delay
dominates), and because of large, fast memories, it will almost always
pay to swap working sets.  however, i believe that it also doesn't pay
to do the swap i/o in units that are larger than what can be accommodated
in a single physical i/o.

for instance, there is often a track size limit on the size of an i/o
transfer.  the system would have to break up larger jobs into multiple
jobs anyway.  in this case, it pays to deal with the working set in
these units instead of the page sized units for both swapping in AND
swapping out.

there is yet another "degree of freedom" which i am examining: preallocation
of memory to reduce memory contention WITHOUT committing to doing any i/o.
i hope to get a paper out of this, so keep your eyes open.

danny chen
ihnp4!homxc!dwc