On Sun, 19 Mar 2000, David Whysong wrote:
> Repeat after me:
calm down.. You know you're in too deep when you try to come up with a
mantra. :)
> You can not solve the OOM problem in user space.
> You can not solve the OOM problem without killing processes.
well... if you could somehow add swap... (by 'borrowing' from a
filesystem).
> Resource limits are not a good solution to the OOM problem.
>
no, limits are not a solution, they are a way of preventing
OOM. Different things.
> I don't like resource limits. Using resource limits is similar to not
> having memory overcommit -- you waste a lot of system resources "just in
> case", the kernel needs to do a lot more accounting, and it's just
> horribly inefficient.
>
well, what's sauce for the goose is not neccessarily sauce for the
gander. What suits you might not suit me.
Indeed what suits me for one box, does not suit me for another box.
ie on one box i might prefer a fast and loose VM, either because i know
the behaviour of the apps i run on it and therefore trust that box not
to OOM, or because maybe that box just isn't that important.
on another box i might need a more locked down VM with quota's and more
extensive accounting of overcommited memory. Possibly because this box
runs potentially hostile/unpredictable apps, or else maybe because this
box HAS to stay up (ie i could lose my job if it doesn't) and therefore
i'm willing to pay in potential VM inefficiency and extra RAM/swap if i
can minimise the risk of OOM.
[snip various arguments circling round OOM]
-paul jakma
[maybe we'll get a /proc/sys/vm/*nazi* in 2.5?]
-
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:29 EST