idea for running out of RAM
Benjamin M. Schwartz
bmschwar at fas.harvard.edu
Fri Oct 31 09:24:56 EDT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Albert Cahalan wrote:
> On Thu, Oct 30, 2008 at 10:05 AM, Erik Garrison <erik at laptop.org> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkkLBygACgkQUJT6e6HFtqSoxwCfdkrCjBJ2RnJFYSt6MjKAsxw8
0k0An14GSYnyJ3PYa0UulLV7Yri18pMG
=tzc6
-----END PGP SIGNATURE-----
More information about the Devel
mailing list