Path: utzoo!utgpu!news-server.csri.toronto.edu!dgp.toronto.edu!jonah
Newsgroups: comp.arch
From: jonah@dgp.toronto.edu (Jeff Lee)
Subject: Re: Translating 64-bit addresses
Message-ID: <1991Feb28.144420.21179@jarvis.csri.toronto.edu>
References: <6590@hplabsz.HP.COM> <12151@pt.cs.cmu.edu>
Date: 28 Feb 91 19:44:20 GMT
Lines: 43

In <12151@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes:
>In article <6590@hplabsz.HP.COM> connors@hplabs.hp.com (Tim Connors) writes:
>> [...]  How could this technique be applied to 64 bit addresses?
>>Would more levels be needed?  Should the page size be larger?

> [...] You can store a complete flat table in another virtual space,
> with pages there only being instantiated on demand.

Full-indexing methods have an outrageous worst-case cost: O(n) in the
amount of space [actually the number of pages] indexed.  This is
managable with today's 4 gigabyte (32-bit) address spaces, but is
insane with a 16777216 terabyte (64-bit) address space.  [What comes
after tera-?]

Making the index sparce helps, but you *still* need to create the
index for the portions of the data that you want to address.  Putting
the index in a virtual space doesn't help very much; it means you can
swap it out, but you still have to construct and maintain the index
(although now in swap space instead of physical memory).  This
complicates the process.

Additionally, the full-indexes often need to be maintained in a form
that is compatible with your MMU, so it can't easily be shared with
heterogeneous machines.  Disk files already have an index of sorts,
but it is seldom compatible with the MMU hardware.  Why build another
index when you map that file into memory?

> You can punt it all to software, if the TLB is big enough, or has big
> or variable page sizes. [...]  Variable page size can be done in
> software. (Mach's boot can select a software page size - of course, it
> has to be a multiple of the hardware size.)

Ultimately, it comes down to software -- especially if you want to be
able to map arbitrary data resources and large shared remote files.
Variable page sizes can help, but as you point out they can be done in
software.

Speculation: In order to deal with growing physical memories we will
soon see TLBs comparable to today's on-chip caches with [tens of]
thousands of entries instead of tens or hundreds of entries as exist
today.

Jeff Lee -- jonah@cs.toronto.edu || utai!jonah