Re: User space out of memory approach

[Ilias Biris <xyz.biris@gmail.com>]

Hi

where I come from we say (jokingly of course) 'got a headache? chop
your own head ... end of problem'.

Though your system is not guaranteed to become more stable. When you
forbid overcommitting memory, all you do is make failure occur for ALL
processes at a different time. A process is happily doing something
useful when all of a sudden its fork may die due to 'out of memory'
... Moreover shutting down overcommit will do that for all processes,
not just the one culprit that could be chopped off by oom...

Maybe it is just me but I think with overcommiting a system works more
reliably :-)


On Tue, 11 Jan 2005 16:32:23 +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2005-01-11 at 08:44, Thomas Gleixner wrote:
> > I consider the invocation of out_of_memory in the first place. This is
> > the real root of the problems. The ranking is a different playground.
> > Your solution does not solve
> > - invocation madness
> > - reentrancy protection
> > - the ugly mess of timers, counters... in out_of_memory, which aren't
> > neccecary at all
> >
> > This must be solved first in a proper way, before we talk about ranking.
> 
> echo "2" >/proc/sys/vm/overcommit_memory
> 
> End of problem (except for extreme cases) and with current 2.6.10-bk
> (and -ac because I pulled the patch back into -ac) also for most extreme
> cases as Andries pre-reserves the stack address spaces.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
Ilias Biris