🚀 go-pugleaf

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.