Tim Bradshaw  <tfb+google@tfeb.org> wrote:
+---------------
| Well, you can buy machines now which can have up to 41 bits of address
| space of *physical* memory in their maximal configuration (128GB per
| board, 16 boards). And this is just machines I know about, there are
| probably larger ones.
+---------------

The SGI Altix 4700 <http://www.sgi.com/products/servers/altix/4000/>
can be ordered with up to 128 TB of main memory, which takes 47 bits
to address, but the IO/memory split takes one more bit, so that's
really 48 bits of physical address in a commercial product *today*!

[By the way, that's with up to 512 CPUs running ccNUMA, with
all of the memory cache-coherently available to all the CPUs
(sequential consistency, same as SMP).]

+---------------
| It's rather unlikely that one of these boxes would be run as a
| single logical host rather than domained, but it could be.
+---------------

The SGI Altix 4700 does that. It's even supported in that
configuration by both SuSE [Enterprise Server 9 or 10] and
RedHat [Enterprise Advanced Server 4 or 5] Linuxes (though
you probably really, really want to add SGI ProPack to get
the extra tuning tools).

+---------------
| So I can foresee machines which would exceed the limit in a few years.
+---------------

Yup.

+---------------
| And that doesn't even start to describe the problem.  What about,
| for instance, wanting to map a (possibly sparse) file? Files can
| be really, really big...
+---------------

Well, now that you mention it...  ;-}  ;-}

SGI's XFS filesystem already supports file sizes up to 9.0e18 bytes,
which is already 63 bits. [It would have been 64, but a Unix/Linux
seek pointer is a signed integer, so you lose the sign bit. They
*do* permit 18.0e18 bytes (64 bits) per filesystem, though.]


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607