Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!ur-tut!tuba
From: tuba@ur-tut.UUCP (Jon Krueger)
Newsgroups: net.arch
Subject: Re: paging and loading
Message-ID: <702@ur-tut.UUCP>
Date: Thu, 18-Sep-86 09:47:35 EDT
Article-I.D.: ur-tut.702
Posted: Thu Sep 18 09:47:35 1986
Date-Received: Fri, 19-Sep-86 22:46:33 EDT
References: <832@hou2b.UUCP>
Reply-To: tuba@ur-tut.UUCP (Jon Krueger)
Organization: Univ. of Rochester Computing Center
Lines: 40

In article <832@hou2b.UUCP> dwc@hou2b.UUCP (D.CHEN) writes:
>...one important aspect that people rarely consider when talking about
>response time and loading is what happens if, in the process of demand
>paging (and loading of "working sets"), memory runs out?  what are
>the implications on response time then?  it would seem that without
>any other aids, pure demand paging is a clear loser in this situation.
>
>danny chen
>ihnp4!hou2b!dwc

Paging systems I'm familiar with handle this in (at least) three ways:

1) When many processes are demanding memory, and system-wide available free
memory becomes low in consequence, per-process limits on physical memory are
lowered.  The operating system shrinks individual process's working sets.
"Times are lean," says the pager, "and we're all going to have to tighten
our belts for a while".  Response time degrades, but smoothly.

2) If all processes have been shrunk to their lowest permissible limits, and
more memory is still needed, someone gets swapped.  Typically someone who
was holding memory but not executable.  "All of us on this lifeboat won't
make it, so some of us have to go into suspended animation until we are
rescued".  This is a mixed paging/swapping system, which shares physical
memory with paging until the sharing gets too thin to do anybody any good.
Then it swaps, thus lowering the demand.  For the survivors, response time
degrades smoothly again.

3) If most processes are swapped out, you're still paging like mad, and
you've run out of good swap candidates, you lose.  A bad candidate gets
swapped out. Lousy response time for him and every one else.  On the other
hand, such cases are examples of trying to substitute virtual memory for
adequate physical memory.  This is also known as belief in magic, making the
wrong tradeoffs, and typical lousy system management.  So I claim it's not
vm's fault, it did the best it could.

-- 
--> Jon Krueger
uucp: {seismo, allegra, decvax, cmcl2, topaz, harvard}!rochester!ur-tut!tuba
Phone: (716) 275-2811 work, 235-1495 home	BITNET: TUBA@UORDBV
USMAIL:  Taylor Hall, University of Rochester, Rochester NY  14627