shrinking memory consumptions

[Ivan Krstić]

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.

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

-- 
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D