idea for running out of RAM

Benjamin M. Schwartz bmschwar at
Fri Oct 31 09:24:56 EDT 2008

Hash: SHA1

Albert Cahalan wrote:
> On Thu, Oct 30, 2008 at 10:05 AM, Erik Garrison <erik at> wrote:
>> Did you continue down this path (auto-saving application state to NAND
>> when we run out of memory)?  How tenable is the idea of saving
>> application state to NAND on our system?
>> Could the oom-killer have a hook to enable this functionality to be
>> invoked instead of simply killing the application?
> OOM is OOM. At that point, something needs to die.
> There is no escape from the cold hard truth that, once
> things have gone bad, it is too late for a good experience.
> Saving state will tend to cause OOM. When software
> does most anything, it needs memory. OOM is a particularly
> bad time to be trying to save state. Don't go there.

I agree... which is precisely why we need the kernel to pause the
offending allocation, and trigger a userspace program, while there are
still (e.g.) 5 MB free.  Call it a "lowmem trigger".  If the process of
servicing the lowmem trigger hits OOM, then we're back to the standard
behavior, but with an appropriately chosen buffer we should have enough
room to close the memory-hogging activity instance without losing user data.

Note that this notion is entirely compatible with per-activity memory
limits.  In fact, they seem to work quite well together.

- --Ben
Version: GnuPG v2.0.9 (GNU/Linux)


More information about the Devel mailing list