> though your example use case makes me feel funny, and not in a good way
mmap is a way of treating files or parts of files as memory when interacting with them and is used pretty often in low-ish level stuff that does file wrangling as it's one of the more performant ways of doing random access on a file. Since those files are being accessed as memory they consume space from the 4 GB of address space on a 32-bit platform, but don't take up physical memory (except insofar as their contents is cached in disk buffers).
That's one thing that's often misunderstood with the 32-bit limitation -- address space is limited; modern "32-bit" CPUs have used 36-bit addressing internally for quite some time, meaning they can address 64 GB rather than 4 GB of RAM (http://en.wikipedia.org/wiki/Physical_Address_Extension).
Because of the address space limitations you also don't have a full 4 GB to work with inside of a process on 32-bit platforms -- if you try to allocate a 3.5 GB block of memory it will usually fail because there's no contiguous block of address space available, even if there's 3.5 GB of unused memory. Typically the Linux kernel reserves 1 GB of address space for itself, and user space reserves a block for memory mapped I/O devices as well.
There's a pretty good article explaining some of this here:
Now, all of that said, I'm not disagreeing with your advice -- just noting that there are some (mostly corner-) cases where you do need the address space, but may not need the physical memory.
Comments
> though your example use case makes me feel funny, and not in a good way
mmap is a way of treating files or parts of files as memory when interacting with them and is used pretty often in low-ish level stuff that does file wrangling as it's one of the more performant ways of doing random access on a file. Since those files are being accessed as memory they consume space from the 4 GB of address space on a 32-bit platform, but don't take up physical memory (except insofar as their contents is cached in disk buffers).
That's one thing that's often misunderstood with the 32-bit limitation -- address space is limited; modern "32-bit" CPUs have used 36-bit addressing internally for quite some time, meaning they can address 64 GB rather than 4 GB of RAM (http://en.wikipedia.org/wiki/Physical_Address_Extension).
Because of the address space limitations you also don't have a full 4 GB to work with inside of a process on 32-bit platforms -- if you try to allocate a 3.5 GB block of memory it will usually fail because there's no contiguous block of address space available, even if there's 3.5 GB of unused memory. Typically the Linux kernel reserves 1 GB of address space for itself, and user space reserves a block for memory mapped I/O devices as well.
There's a pretty good article explaining some of this here:
http://kerneltrap.org/node/2450
Now, all of that said, I'm not disagreeing with your advice -- just noting that there are some (mostly corner-) cases where you do need the address space, but may not need the physical memory.