shrinking memory consumptions

[Jens Axboe]

On Mon, Apr 02 2007, Jim Gettys wrote:
> On Mon, 2007-04-02 at 13:01 -0400, Ivan Krsti?? wrote:
> > Jim Gettys wrote:
> > > It need not be arbitrary: it can be the activity that was used longest
> > > ago/crossed by total memory usage. 
> > 
> > That's arbitrary. Please, please don't keep going down this road of
> > thinking -- you can't develop better heuristics than asking the user
> > what she wants to close. Ask the scheduler guys how much of a PITA it
> > was for them to insert little sleep counters all over the scheduling
> > code so that they could, in theory, prioritize "active" applications for
> > scheduling... and how fragile it was, and why a bunch of people are
> > thrilled by Con Kolivas' recent RDSL work that'll completely get rid of
> > such heuristics when it gets merged.
> 
> Having apps save themselves periodically so they can be transparently
> restarted is I think the right goal.

Yep, some checkpointing and restarting is awesome. Getting killed is not
so much of an issue, if you can go right back to where you were. It's
quite handy for firefox, for instance :-)

> > > 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.
> > 
> > You can do that today; /proc/x/oom_adj and check your current score via
> > /proc/x/oom_score. But we can do better -- our efforts should go towards
> > not hitting OOM in the first place.
> > 
> > > Warning from the kernel doesn't work: you can deadlock.
> > 
> > No. A notification mechanism, as I propose, should be completely
> > orthogonal to the OOM killer. It's a "hm, we have 5 megs left, warn
> > userland, maybe they kill something and we never hit OOM" approach. If
> > we do hit OOM, let the OOM killer do its thing. I'm clearly not
> > proposing that it block on an answer from userland. I'm proposing
> > essentially an optimization that turns an already-viable solution into
> > something that we don't have to poll.
> > 
> 
> Sorry: that's not the way the kernel works; for example, in can come
> packets, and you can't wait on user space to do anything.  I've already
> been down this path with true kernel guru's....
> 
> At best you can tell the kernel what order in which to shoot things, and
> that capability is there.

I don't think Ivan's idea is totally insane, technically it's doable and
not deadlock prone if you can do it in time. It wont work if you defer
it to the point of OOM, naturally. But it's more involved, if you can
save state and restart processes then you've already eliminated much of
the pain of getting OOM killed.

-- 
Jens Axboe