[plug] upper RAM size limits in Linux

[Quintin Lette]

All these problems disappear with 64bit ;-)

possible options SPARC 64 - Opteron - Itanium - G5 .. among multiple 
others ;-)

As an example TYANs Dual Opteron board supports 12GB of Registered DDR ram.

As far as architecture is concerned, full 64bit is capable of addressing 
somewhere around 4500 TB of memory compared to the meager 4GB of 32bit there 
are obviously limitations.

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.

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.

Cheers

Quintin

Disclaimer: I don't claim to be an expert in this area, this is just my 
personal opinion.

On Tue, 2 Dec 2003 09:27 pm, Denis Brown wrote:
> Dear PLUG list members,
>
> I have a "nice" problem :-)  Am about to order a couple of gritty
> workstations and servers for a medical imaging laboratory.  On the server
> side we're talking dual Xeon 2.8GHz, hardware RAID, initially 0.4TByte
> disk space across three spindles, U320 SCSI and now the question... Budget
> will probably allow up to 4 GByte RAM, possibly more, but isn't 4GByte the
> upper addressable limit anyway given the bus width?   Too late in the
> night for my math cells to function :-(
>
> On the workstation side, single Xeon 2.8GHz, single SCSI320 drives and ???
> RAM with gigabit links between server(s) and WS(s).   Since this is
> imaging, the more RAM the better but is there a practical upper bound in
> Linux?   I've seen reference to having to specify memory size (in
> lilo.conf???) but I think that was in the Bad Old Days (tm)
>
> As an example of the sort of memory requirements there was a message on
> one of the imaging lists tonight suggesting that 3GByte swap would be
> appropriate for some functional MRI work - file sizes for a single study
> 500MByte, and we generally average 100 of those from a population to
> create normalised templates for subsequent analysis.   (Do not try this on
> your abacus!)
>
> I did some Googling but haven't found much on the topic since about Feb
> 2000, when a discussion on the kernel archive talked of brk() having an
> upper bound of 900MByte and mmap() up to 3GByte.   There was some talk in
> the same thread about getting the glibc people to opt for the 3GByte limit
> by default.
>
> TIA,
> Denis
>
>
> _______________________________________________
> plug mailing list
> plug at plug.linux.org.au
> http://mail.plug.linux.org.au/cgi-bin/mailman/listinfo/plug