OOM killer and such [LWN.net]

OOM killer and such

Posted Jan 24, 2008 2:55 UTC (Thu) by Richard_J_Neill (subscriber, #23093)
In reply to: OOM killer and such by corbet
Parent article: The Grumpy Editor's video journey part 2: Video editors

On a 32-bit system, no single app can use more than 2GB of RAM (if I understand correctly). So
3GB won't help very much. This is a particular pain, because even when running a
memory-monitor on the taskbar, you can't easily see whether one particular app is about to run
out of addressable RAM. 

That's why my new desktop machine is 64-bit, so that firefox can address almost 8GB of real
RAM, and furthermore, leak into 16GB of swap, before it finally crashes!

(Log in to post comments)

OOM killer and such

Posted Jan 24, 2008 3:48 UTC (Thu) by corbet (editor, #1) [Link]

The virtual address space on a default-configured 32-bit system is 3GB. In any case, you don't bring in the OOM killer by running out of virtual space.

But, in any case, the system in question is a 64-bit machine, so all that is moot.

Single app vs. single malloc()

Posted Jan 25, 2008 22:54 UTC (Fri) by AnswerGuy (subscriber, #1256) [Link]

On 32-bit x86 Linux systems with a standard libc the largest chunk of contiguous memory
available to any process is ~2GB; there are some dribs and drabs (about another half-GB)
available after that.

This has to do with how libc aligns its ELF segments relative to the heap.

On PAE enabled systems one can have multiple different processes each with their own 2+GB of
allocated memory.

Interestingly I've heard that 32-bit processes running under a 64-bit kernel can get much
closer to 3GB contiguously allocated.  I guess the kernel is able to stay completely out of
the way in that case.

Unfortunately I haven't found any really good URLs that describe this in sufficient detail
(with sufficiently comprehensible diagrams) that I can really recommend them.  And my
comprehension is limited --- so I can't explain it better nor draw the diagrams that I'm
eventually hoping to find.

(It's unfortunate because I work at a company that makes EDA software --- which is notoriously
memory hungry.  So the question comes up far too often, despite the accelerating adoption of
64-bit systems).
JimD