On Wed, 15 Mar 2000, James Sutherland wrote:
> On Wed, 15 Mar 2000, Paul Jakma wrote:
> > so isn't what should be concentrated on? Per user limits are a cleaner
> > way of fixing the problem.
>
> They would AVOID the problem in a lot of cases - but not always.
avoid is what i meant.. sorry..
> Yes, we should have per-user resource limits. Yes, they would help
> prevent malloc-bombs from being effective. No, they will not
> *prevent* OOM situations arising.
no they won't, of course not. risk of OOM is a feature of an
overcommiting VM. no way round it.
>
> > OOM is a stopgap. Ideally we should be able to set ironclad policies so
> > that we never encounter OOM.
>
> I doubt that could really be achieved. Dynamically reducing user rlimits
> to try to prevent them overloading the system would ALMOST achieve this
you could do it with a damon..
> -
> but what if a root process blows up? What if a couple of users all hit
> their resource limits at once? While individually they may not have high
> enough resource limits to OOM the box, a group of users would still be
> able to.
>
note that i said "be /able/ to". Ie If as admin could limit each user in
@users to 50MB of address space on a 4 user box, then i just need to
make sure that i have > 200MB of RAM+swap, to know that i will never OOM
because of @user processes.
most people though would accept more risk with potential OOM for more
flexible VM usage.
It'd be nice to have that choice. And i'm pretty sure per-user VM
beancounting would allow me to pretty much reduce risk of OOM to close
to 0 on my boxes..
> make this almost impossible - but never completely.
>
of course, i wouldn't suggest otherwise. OOM is a risk you take with
just about every present day OS.
>
> James.
-paul.
-
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:17 EST