Re: [PATCH] Remove OOM killer from try_to_free_pages / all_unreclaimable braindamage

[Werner Almesberger <wa@almesberger.net>]

Bodo Eggert wrote:
> You'll have some precompiled binaries causing trouble, while other
> precompiled binaries will be killed while you want them to stay alife.

That's why you could use a wrapper.

> Sometimes you'll have the same binary (e.g. perl or java) running a
> "notme"-task like watching the log for intrusion while at the same time
> processing a very large image.

The wrapper could also not be part of the regular execution, and
you'd only use it if you really need it, much like nice, chroot,
etc.

> The best solution I can think of is attaching a kill priority (similar to
> the nice value). Before killing, this value would be added to lg_2(memsize),
> and the least desirable process would "win", even if it's sshd running wild.

I'm extremely sceptical about solutions that require the user to
quantify things. In the world of QoS, if you give users a knob
to play with, the'll stare at in confusion, and ask for the
"faster" button. I don't think the OOM case is much different.

A "victim" (or a "precious") flag has the advantage that the user
doesn't need to estimate peak demands, but still doesn't depend
solely on the verdict of some arcane algorithm working behind
the scenes.

> For the trashing problem: I like the idea of sending a signal to stop the
> process, but it should rather be a request to stop that can be caught by
> the process.

Good idea. That would also help with the problem of browsers
immediately asking to be brought back to life, so that they can
spin the banner ads some more.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/