lkml.org 
[lkml]   [2000]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Some questions about linux kernel.
On Thu, 16 Mar 2000, Paul Jakma wrote:
> 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.

No, it's a risk with any system with finite memory.

> > > 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..

Perhaps...

> > 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.

Right... Shall we try that on the mail system here? (People telnet in to
read mail via Pine). 25 000 users, 4Gb RAM... Let's assume it has 21Gb of
swap, too. So users get a VM quota of an entire megabyte of RAM! That's...
Enough to log in with! (just).

Not really practical in a serious multi-user box. Fair enough if you have
a handful of users, I suppose - but we have Linux boxes here with several
hundred users. Restricting their memory usage to 1Mb each is hardly
practical - try compiling and running Java applets etc. in 1Mb??

> 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..

On a small box, yes - provided NOTHING runs as root.

> > 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.

No, it's a risk with ANY OS which allocates memory. Even a single-tasking
OS with no concept of security, like Win2k^H^H^H^H^Hthe BBC Micro MOS, can
run out of memory - you just use it all.

IRL, there's not a lot you can do to prevent applications eating up all
your memory. You can reduce the risk in some ways, but there isn't a
perfect solution...


James.


-
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/

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