🚀 go-pugleaf

<>
As memory prices drop and other economic things come to pass,
suddenly we have people asking for big fast memory.  Maybe RAM,
maybe SUPER disk, maybe super-cooled core.  Whatever it is going
to be, paging will still go on.  (Atleast thats a best guess, but
I digress)

Decoding an address is a look up.  Simple cascades will not cut it in
the GB or TB range (you laughed at the first guy who said Gig, how
about Tera! :-).  Log(n) is nice, but seconds (plural) is not all that
fun for finding a page, even if you go for 8,16 legged trees (base
8,16).

Perhaps having clusters of pages, grouping allocations.  This would
help for 2000+ user systems (giving everyone their own cluster or even
one per process), but would fail miserably for the 2GB data base.
Each process having a page translation table, and a VM system which
could grok processes or would only look in one place (via another
translation table perhaps).

It keeps coming back to that translation.

Well how about a mix.  A reasonable N MB of virtual memory paged
by whatever scheme you have in hand, and  N TB of physical memory
mapped way out somewhere.  You could have the real near and the
virtual far if you wanted.  Probably easier for faulting and all
that noise.  You still have a VM machine, its just that the VM
is way out there where you may not have to use it.

Yes, this rapes the virtual memory environment.  Segmentation comes
to mind as something to put on top of the two for protection and
address monkeying (every process gets to have its space start at 0
or whatever makes life easy).

Dabble, yes, flames if you must, please be informative with them.

-- 
    Jim Hutchison   UUCP:	{dcdwest,ucbvax}!sdcsvax!hutch
		    ARPA:	hutch@sdcsvax.ucsd.edu
	"Disclaim, disclaim, off to post I go."