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. *ANY* memory allocation system can run out of memory. Avoiding
"overcommitting" would make the OOM situation arise SOONER (and more
frequently), as well as killing performance.
> > > 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..
Yes, that's what I had in mind.
> > 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... Now we'll try this on the university's central Unix system, shall
we? Let's see... 6000 users, 2Gb RAM+swap. They get about 300K each.
That's ALMOST enough to log in with!
> most people though would accept more risk with potential OOM for more
> flexible VM usage.
The alternative just isn't practical in any real-world situation, except
more-or-less single user boxes. Even then, that single user will still run
out of memory - it's just his quota, rather than a physical limit.
So his processes STILL end up dying randomly, but they do it sooner rather
than later. Hrm. Wow.
> 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 any realistically specced box, it is almost zero already.
> > 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 *EVERY* OS. My mobile phone can (in theory) run out
of memory. Every computer which has ever allocated memory in any way can
run out of it.
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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:17 EST