🚀 go-pugleaf

/* Written  5:51 pm  Aug 28, 1986 by phil@osiris.UUCP in datacube:net.arch */
.......
Now.  By adding more main memory, you *do* decrease paging, which
is obviously a good thing.  However, you also make memory mapping
more time-consuming (more page table entries to maintain), so
there's a tradeoff here.  You might be able to expand the memory
to, say, 16M without taking any hits - the upper limit depends,
of course, on your VM archi- tecture.  Beyond this limit, the
page table has to be expanded, and maintaining it becomes more
complicated.  Eventually you reach a point where the time saved
by not paging is less than the extra time spent maintaining the
mapping table.  This is the point where you should just give up
trying to speed up your system by adding more memory.

Is this right?  It's sort of off the top of my head, and I may
have gotten some of the details wrong (what details, I hear you
ask?) but it seems to convey the gist of the argument...

Phil Kos			  ...!decvax!decuac
The Johns Hopkins Hospital                         > !aplcen!osiris!phil
Baltimore, MD			...!allegra!umcp-cs
/* End of text from datacube:net.arch */

I agree with this for fixed VM architectures, but for  new machines I
would think that the page size should be increased so that the number
of  pages  of  physical  memory  available  remains roughly constant.
Won't this give ever increasing performance, or does the latency time
of bringing in new pages kill the gains?  

BTW, a quick calculation tells me that with current  technology a 128
Mbyte memory board could be designed for the  SUN-3, (15"  X 15" form
factor).  This would include error  correction and  detection and all
the other goodies required  on big  system memorys.   Just  slap 8 of
these in your SUN3-160, instant Giggabytes.  

1Gb == 45 seconds color video.			      John Bloomfield

Datacube Inc. 4 Dearborn Rd. Peabody, Ma 01960 	         617-535-6644
	
ihnp4!datacube!john
decvax!cca!mirror!datacube!john
{mit-eddie,cyb0vax}!mirror!datacube!john