Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!gatech!seismo!lll-crg!gymble!umcp-cs!mangoe
From: mangoe@umcp-cs.UUCP (Charley Wingate)
Newsgroups: net.arch
Subject: Re: 128Mb - I give up!
Message-ID: <2496@umcp-cs.UUCP>
Date: Mon, 9-Dec-85 00:58:15 EST
Article-I.D.: umcp-cs.2496
Posted: Mon Dec  9 00:58:15 1985
Date-Received: Wed, 11-Dec-85 03:03:30 EST
References: <285@frog.UUCP> <3900004@iuvax.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 17

Maybe I just don't understand, but I do think there comes a point where
more memory just isn't going to help significantly.

Let's look at this in terms of pages.  With a proper replacement algorithm,
the paging rate is always going to decrease asymptotically toward zero as
the number of pages in memory increases.  Ignoring the overhead of context
switches, the "right" amount of memory is that in which the page faults are
generated no faster than the paging drives can handle them.  In practice,
some extra margin would be needed; some to reduce context swapping, and some
to reflect the statistics of paging better; by playing games with queuing
theory, a better number can be obtained.

I don't have any figures one me, but I suspect that the tremendous speed
differential between disk and CPU is going to set a high limit-- especially
when the statistics come into play.

Charley Wingate