Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site wu1.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!floyd!cmcl2!rocky2!cubsvax!wu1!rf
From: rf@wu1.UUCP
Newsgroups: net.unix-wizards
Subject: The performance of paging virtual memory systems
Message-ID: <202@wu1.UUCP>
Date: Thu, 8-Dec-83 20:17:22 EST
Article-I.D.: wu1.202
Posted: Thu Dec  8 20:17:22 1983
Date-Received: Sun, 11-Dec-83 00:39:40 EST
Organization: Western Union Telegraph, Mahwah, NJ
Lines: 78

Paging is not useful in all computer applications.  It seems to
me that it has these uses:

  - It allows one to gracefully trade program execution speed
    for main memory.  This is very important in large shops that
    mainly run a few huge systems.  If one has just added a user
    to the thousand-user on-line system (and these are more
    common than one might think) it does not do to discover that
    it no longer fits in main memory.  One *cannot* shut down a
    system of such size for more than a day and that new office
    may not be able to do without the computer.  Virtual memory
    provides a graceful way to support that new office while you
    are waiting for more physical memory.

  - It provides better memory utilization when you have very
    large programs on your computer.  It does not do to have to
    swap *all* of an eight million byte program.  On a machine
    with a slow disk (like mine) even a quarter million byte
    program takes a while to swap.

  - It provides a way to develop large programs before the new
    hardware has arrived.

  - It can provide fast interprocess communication (by quickly
    moving pages between address spaces) and flexible memory
    sharing.

  - It can provide an elegant alternative to overlays.

  - It can provide an elegant mechanism for dealing with large
    files.

In a paged environment you usually encounter the following
problems:

  - There is a temptation not to adequately monitor hardware
    usage, especially when company management does not want to
    hear about spending money.

  - You may not be able to buy adequate monitoring
    subsystems.  Indeed, I know of no such systems for Unix.

  - Paging can use up disk seeks and memory bus time in
    unexpected ways.  If a database and a paging file are
    sharing the same disk or i/o channel, expect problems.  For
    good use of your system, you usually have to reserve at
    least one disk drive for paging.  This in itself leads to
    problems--what happens when that one drive fails?

  - Some systems do not set limits on user process address
    space.  Many programs will quite happily expand to a
    machine's full virtual address space.  A good page manager
    must set per-user address space limits.  The possibilties
    for intentional abuse are even worse.  It is not hard to
    write a program that send an OS/MVS system into fits of
    thrashing.  Unless your operating system's process scheduler
    knows to drop the priority of a thrashing process (does BSD
    Unix's?) your system is horribly vulnerable to such
    problems.

  - Some page managers have no notion of "working set."  This
    guarantees page thrashing.

  - It's sometimes useful for an applications program to give
    hints to a page manager, but I know of only one page manager
    which allows this (VAX/VMS.)


There are very few operating systems which make time-efficient
use of paging.  OS/MVS and VM/CMS are unhappy examples of
systems which do not.  VAX/VMS is a happy example of a
well-planned paging system.  Paging is sometimes a useful
capability.  It is not one which is to be lightly included in a
system.


					Randolph Fritz
					Western Union Telegraph