On Tue, 14 Mar 2000, bert hubert wrote:
> The code bloat involved in checking each and every function call will also
> cause lots of OOMs which otherwise would not have happened :-)
>
if it's done inline it should already have been allocated. :)
> > linux has never been afraid of calling a spade a spade. And it has never
> > gone out of its way to support bad apps. If crucial system daemons are
> > broken wrt to OOM then they should be fixed, not worked-around.
>
> Being OOM mostly does mean that something is broken.
>
and it's typically not in a system daemon. and if it is, cause they're
such standard and widely used things, the problem will be noticed
quickly and hopefully fixed quickly. The problem is with apps that
people run on their systems, be it netscape/oracle/long running
simulations.. etc.
anyway this is going round and round and round...
some sugestions so far:
a) turn off overcommit.
- not at all practical.
b) Implement an OOM killer
- objections stem mainly from the many different possibilities. To be
101% reliable OOM killer would need telepathy.
c) Reserve memory for root in some way
- offending process could be root owned though. Still, it leaves policy
to admin whether to trust a process as root, and in some cases it is
preferable for admin to clean up rather than rely on a kernel grim
reaper.
d) per user limits
- this'd be real nice to have, and a step forward from per-process
limits. But what of the efficiency costs? And if someone implements it,
-> 2.5+.
so when all is said and done we're just going to have wait and see what
Andrea/Ingo/Rik et al come up with, aren't we?
> Regards,
>
> bert hubert.
>
regards,
-paul jakma
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:18 EST