🚀 go-pugleaf

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.

>>desireable to make the pages large.  That way you can take advantage of the
>>fact that most I/O comes from consecutive disk locations - therefore there
>>are fewer seeks with large page size.

I have never seen a disk system that did not fragment. Unless the disk
page size was also similiarly large. Upon which you get lots of wasted
space, because most files are about 1K long or so, and you'd have
these mungo 16K disk pages only 1/16th full... Imagine, a 160 megabyte
disk with only 10 megabytes used on it, totally full.

>>J. Giles
>>Los Alamos
>
>important than overall throughput. Anyone who was around in the days of
>"batch only" knows this argument inside and out. Batch is fine if you want
>to maximize individual program performance, but overall turnaround time is 
>dreadful, since ALL things sit in the queue, including the 1/2 second
>practice runs.

Very good point. See my article elsewhere about the performance
drawbacks of paging (which are so minimal as to be ridiculous).
-- 

      Eric Green {akgua,ut-sally}!usl!elg
        (Snail Mail P.O. Box 92191, Lafayette, LA 70509)

" In the beginning the Universe was created. This has made a lot of
 people very angry and been widely regarded as a bad move."