Re: Avoiding OOM on overcommit...?

From: Marco Colombo (marco@esi.it)
Date: Tue Mar 28 2000 - 08:06:02 EST


On Tue, 28 Mar 2000, Peter T. Breuer wrote:

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

The problem does not occur when the kernel is trying to page *you* out.
It occurs when the kernel is tring to page *another process* out.

>
> Peter
>

.TM.

-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

- 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:22 EST