idea for running out of RAM

[Albert Cahalan]

On Fri, Oct 31, 2008 at 9:24 AM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> Albert Cahalan wrote:
>> On Thu, Oct 30, 2008 at 10:05 AM, Erik Garrison <erik at laptop.org> 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.