Re: Avoiding OOM on overcommit...?

From: Peter T. Breuer (ptb@it.uc3m.es)
Date: Mon Mar 27 2000 - 18:18:24 EST


"A month of sundays ago Linda Walsh wrote:"
> Horst von Brand wrote:
> > I can understand there are people worried by stuff like C2 security, but in
> > that case you can work with overcommitment, just make sure the tasks
> > crucial for C2 can't run out of resources (unless they are broken or the
> > sysadmin is a complete idiot, that is), and then do as you say: If they do
> > run out, take the whole system down.
> ---
> Well -- that's sorta the point -- Everything from 'atd' to 'vi'
> would need to be rewritten to 'touch' pages of alloc'ed memory. If you want

Where do you get this from? Just change the malloc they use in libc.
This used to be commonly done to protect netscape from itself
(LD_PRELOAD = gnumalloc.o). This is and always has been trivial.

> The idea here is to *prevent* overcommitment. OOM can't be
> prevented, but if you have eliminated overcommitment, how OOM is handled

Overcommitment is fine. If you don't want it, reserve your own backing
swap space for your stack. That's all. Then you can't be murdered by
the kernel because the kernel will always be able to page you out.

Peter

-
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 : Fri Mar 31 2000 - 21:00:21 EST