Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!rutgers!sri-spam!nike!ucbcad!ucbvax!decvax!decwrl!pyramid!prls!philabs!linus!raybed2!applicon!bambi!maggot!barada From: barada@maggot.UUCP Newsgroups: net.arch Subject: Re: paging and loading Message-ID: <800002@maggot> Date: Thu, 16-Oct-86 14:00:00 EDT Article-I.D.: maggot.800002 Posted: Thu Oct 16 14:00:00 1986 Date-Received: Tue, 21-Oct-86 20:54:00 EDT References: <949@usl.UUCP> Lines: 74 Nf-ID: #R:usl.UUCP:-94900:maggot:800002:000:3400 Nf-From: maggot.applicon.UUCP!barada Oct 16 14:00:00 1986 Written 2:47 am Sep 27, 1986 by usl.UUCP!elg >In article <78@alberta.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes: >>In article <7597@lanl.ARPA> jlg@a.UUCP (Jim Giles) writes: >>> >>>Note that the computational speed of the Cray really does exceed I/O speed >>>by about a factor of 10^6 - page faults in this kind of environment are >>>EXTREMELY costly. > >Not at all. The I/O processor does all the work of reading a page off >of disk and stuffing it into memory (via DMA). Meanwhile, the CPU goes >off and runs somebody else's job, taking advantage of that explicit >multiprocessing. Assuming you're not using the entire machine for a >single batch job, that is. So even if you have a working set larger >than available memory, if you have a good scattering of jobs so that >thrashing doesn't occur, the CPU still gets the same amount of work >done -- it's just divided amongst users, instead of all happening to >the same process. > > Also note that page faults do not occur unless the working set of the >program exceeds available physical memory -- if a page fault occurs, >it means your program wouldn't have run without paging, anyway. And if >a page fault DOESN'T occur (that is, if the program would have run in >physical memory), then you can discard the overhead of page faults >altogether, and just concentrate on the overhead of virtual address >translation. Loading is loading. Loading 64K of data via 8 page faults >should not be any more expensive than loading 64K of data in one fell >swoop. > Your arguement is good, but it does have its weaknesses: 1) The CPU would not get the same amount of work done in page faults since the context switches occur, and the kernel has to reschedule running processes and biases. So a program that goes page-fault happy (such as a monster hashing algorithm) would actually cause the WHOLE system to run slower due to all of those pagefaults spending time in the scheduler. 2) What do you do if two processes each need 80% of the available memory? run one so it doesn't fault and then run the other? This is great for Batch systems, not timesharing. Actually, a good design would try to balance it out by allowing each a page set that takes up half of memory. This would give each about the same probability(theoretically) of having the proper page in memory. Now if one process runs in only 10% of its Workspace, then the workspace can be reduced to allow the other piggish process a better chance of having a page hit. So the likelyhood of a process having its WS available is better if the process is small. But if it is really large, then that likelyhood is inversely porportional to the WS needed. So really large processes run even SLOWER since they can not get the large WS unless they run in a `batch' style. The calculations to determine the adjusting of the WS is done on each pagefault, which can slow things down even more for huge systems. I am not faulting VM systems for crays, I'm just pointing out some things that were overlooked. -- Peter Barada | (617)-671-9905 Applicon, Inc. A division of Schlumberger Ltd. | Billerica MA, 01821 UUCP: {allegra|decvax|mit-eddie|utzoo}!linus!raybed2!applicon!barada {amd|bbncca|cbosgd|wjh12|ihnp4|yale}!ima!applicon!barada Sanity is yet another perversion of reality.