shrinking memory consumptions

[Jens Axboe]

On Mon, Apr 02 2007, 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.

That remains to be seen. I'm sure I don't need to remind anyone of
Brooks' 2nd and 3rd system redesign principles :-)

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

Yep I agree with that, if possible we should definitely avoid getting
into OOM in the first place.

-- 
Jens Axboe