The performance of paging virtual memory systems
r...@wu1.uucp
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
Mark Callow
> hints to a page manager, but I know of only one page manager
> which allows this (VAX/VMS.)
4.[12]BSD also allow applications to give hints to the page manager
through the vadvise system call. 4.2BSD has more capability in this
area than 4.1BSD.
--
From the Tardis of Mark Callow
m...@qubix.UUCP, decwrl!qubix!m...@Berkeley.ARPA
...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!msc
ma...@umcp-cs.uucp
- 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.)
Randolph Fritz
Western Union Telegraph
Berkeley Unix allows these hints too, via the "vmadvise" system call.
--
spoken: mark weiser
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!mark
CSNet: mark@umcp-cs
ARPA: mark.umcp-cs@CSNet-Relay