-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Albert Cahalan wrote: > On Thu, Oct 30, 2008 at 10:05 AM, Erik Garrison <[EMAIL PROTECTED]> 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----- _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
