Article View: net.arch
Article #2872Re: paging and loading
From: Jon Krueger
Date: Thu, 18 Sep 1986 13:47
Date: Thu, 18 Sep 1986 13:47
40 lines
2681 bytes
2681 bytes
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
Technical Details
Message-ID:
<702@ur-tut.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!rochester!ur-tut!tubaReferences:
<832@hou2b.UUCP>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!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