[lkml]   [2000]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Some questions about linux kernel.
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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.093 / U:1.332 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site