On Fri, Oct 31, 2008 at 9:24 AM, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: > Albert Cahalan wrote: >> On Thu, Oct 30, 2008 at 10:05 AM, Erik Garrison <[EMAIL PROTECTED]> wrote:
>>> 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. This tends to fail horribly. Early detection of low memory is unreliable. Also, you have no idea if "5 MB" is too much or too little unless you get some guidance from activities. Even if you succeed, you have failed. At best you have forced an activity to die, which is really not what the user would like. Most likely, you also get data loss. (because the system thrashes and the user cuts power, or because the activity doesn't implement an emergency save feature that can reliably operate from any program state, etc.) It's quite unlikely that the majority of activities will have a reliable and useful response to a low-memory signal. This is asking a lot from developers, even if you ignore all the less-sugary activities. > Note that this notion is entirely compatible with per-activity memory > limits. In fact, they seem to work quite well together. memory limits != memory reservations Memory limits create needless failure. Random user software can not be expected to have a useful response to memory allocation failures. The most you can hope for, and this is a great big **hope**, is that sudden death is non-corrupting. We have a problem with hitting the hardware memory limit. Adding an extra limit just increases the problem. Instead of continuing until the user gives up, a non-hardware memory limit causes an early failure. One might as well just ship less RAM if earlier failure is the goal! Memory reservations are a different beast entirely. Running out of memory becomes approximately impossible because the user is blocked from starting too many activities. Memory reservations mean this: "Don't start something that you can't finish." or "Don't bite off more than you can chew." or "Don't make promises you can't keep." Memory reservations are fairly easy for everybody. You can implement them entirely in the program launcher. Activity authors don't need to write any code; they merely need to place a number in an activity.info file if they wish to participate. _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
