shrinking memory consumptions

[Jim Gettys]

On Mon, 2007-04-02 at 12:41 -0400, 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.

It need not be arbitrary: it can be the activity that was used longest
ago/crossed by total memory usage. And key processes should never be
touched.

And we can warn applications to save their state, for restart at a given
state.

This is only slightly a kernel issue.  What's really needed is for user
space to tell the kernel what the priorities are on what to shoot.

The additional complication is that applications also use memory in the
X server, which is not getting counted against them.  We need some way
to inform the OOM system (not the kernel killer) current usage, so that
it can choose the right thing to shoot.

> 
> 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.


Yes, the Nokia folks have been doing the most; a few may be on this
list, and I sent you contact information in other mail.  They've told me
(some of) their code will be coming available: I've not had time to
follow up recently.

Warning from the kernel doesn't work: you can deadlock.  What you can do
is have user space prioritize what should get shot, and tell the kernel
what to do.  This needs to be a cooperative venture.


> 
> 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".
> 
-- 
Jim Gettys
One Laptop Per Child