shrinking memory consumptions

[Jens Axboe]

On Mon, Apr 02 2007, Ivan Krsti?? wrote:
> Jens Axboe wrote:
> > Didn't figure I would :-) And yeah, I don't mind taking a look at low
> > memory and OOM situations.
> 
> I don't really know that there's that much to work on with regards to
> OOM. When we hit OOM, we've lost already -- we need to make an arbitrary
> decision to kill something, and there's no good heuristic to make sure
> we don't kill whatever is most precious to the user at the moment.

OOM is pretty simple to get right, when you have the chance to tailor it
to a custom setup like this one. In general it's next to impossible to
get right. But that is why I made the distinction between low mem and
OOM.

> In my mind, the OOM solution is a relatively straightforward one: when
> -- sans buffers and cache -- we've allocated 256-x MB, with x being 5 or
> 10, the kernel emits a warning to userland through some interface
> (netlink? something else we can epoll?). Sugar picks up warning, freezes
> execution of currently-running activity, and gives the user a "low
> memory; pick an application to close" chooser. After the user makes the
> selection, the target application is sent a 'save anything you have open
> and emergency close' message via D-BUS, and terminated seconds later if
> it fails to comply. If I remember correctly my conversation with Sampsa
> of the Maemo team at Nokia, they wanted to do something similar.
> 
> All of the above can be implemented today, except we'd have to poll;
> optimizing that to be epollable is worth it, but either way, I strongly
> believe OOM should be a last resort, not a "solution".

Of course, OOM is always just a last resort. It'll get rid of an
application, but it's not very polite. I like your approach with a gui
warning and all, it'll work fine as long as the rate of memory
allocations doesn't get you into problems before the user has selected a
process to (checkpoint, if possible, and) quit.

-- 
Jens Axboe