Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site sdcsvax.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!jc From: jc@sdcsvax.UUCP (John Cornelius) Newsgroups: net.arch,net.unix-wizards Subject: Re: page-up problem/question Message-ID: <401@sdcsvax.UUCP> Date: Sat, 20-Oct-84 17:16:22 EDT Article-I.D.: sdcsvax.401 Posted: Sat Oct 20 17:16:22 1984 Date-Received: Sun, 21-Oct-84 15:31:18 EDT References: <895@opus.UUCP> Reply-To: jc@sdcsvax.UUCP (John Cornelius, Western Scientific)) Distribution: net Organization: EECS Dept. U.C. San Diego Lines: 27 Xref: 626 10046 The 2 extremes of the problem you articulate are: 1) bring in the initial startup page and page fault everything else in 2) bring the entire text into memory (if possible) and allow pages to be replaced arbitrarily by the demand paged system as other requirements for the space occur. In the first case you get an arbitrary collection of pages scattered throughout memory and every time there's a page fault you pay with the time required to service it. In the second case you pay on the front end by bringing in everything at once and then you pay again as small chunks (pages) get deallocated by the requirements of others. It's funny how some things never change. We still, after 30 years in this business, have to trade off speed, money, and memory. The whole discussion becomes moot if one has adequate memory for all requirements but that only encourages more (Parkinsonian) requirements for the available resources. One has to start with whatever is a given, use whatever gimmicks one has to overcome the starting limitations, and then go ahead and have a homebrew because there isn't any best solution. John Cornelius Western Scientific