[plug] upper RAM size limits in Linux

[James Devenish]

In message <200312022157.11069.quintin at arach.net.au>
on Tue, Dec 02, 2003 at 09:57:11PM +0800, Quintin Lette wrote:
> At a pricing point an Opteron 242 is close to a Xeon 2.8, Opterons also work 
> in 32bit mode, and I don't recall this with Linux, but with Mac OSX and the 
> G5s there is 64bit memory addressing for the 32bit OS, and I would be 
> surprised if no-one has done something similar in Linux.

Some additional points:
 - I recall RedHat having difficulty with gcc's linker because it didn't
   have provision for selecting the right ABI under mix-mode
   architectures (e.g. UltraSPARC). I assume the same would apply to
   G5s. It's obviously advantageous to have a mixed system because you
   can use products off-the-shelf. Presumably, gcc's linker limitation
   wouldn't have been a problem unless Linux already supports mixed-mode
   operation.
 - Though I don't know about Linux, stock-standard 32-bit processes
   doing plain-old malloc would typically be hard-limited to 4Gb (and be
   aware of your configurable 'ulimit'), though of course with a 64-bit
   kernel, 64-bit processes aren't limited to 4Gb (and 32-bit process
   may have ways around the limit, with some footwork on the part of
   developers).

> All these problems disappear with 64bit ;-)
[...]
> The 64bit option also allows a lot of head room for upgrades, etc that aren't 
> available when you are starting at the ceiling of 32bit.

Some additional points:
 - if you're working with large data sets, using a 64-bit architecture
   with 64-bit OS userland basically means freeing yourself from the
   vagueries of things like 'large file support', transitional
   interfaces, etc.
 - depending on your architecture, having native 64-bit numeric types
   (integers for floating-point) may on save overheads if your
   applications would otherwise be simulating 64-bit data types.