Re: Avoiding OOM on overcommit...?

From: Horst von Brand (vonbrand@sleipnir.valparaiso.cl)
Date: Wed Mar 29 2000 - 21:00:10 EST


"Peter T. Breuer" <ptb@it.uc3m.es> said:
> "A month of sundays ago James Sutherland wrote:"
> > On Sun, 26 Mar 2000 17:50:37 +0200 (MET DST), you wrote:
> > >And I arrived later too. But while we're on the subject of swap space,
> > >doesn't "reserve me 8MB of disk-based swap as backing for my stack" cure
> > >everyones OOM blues? I propose that that's a fair use for swap nowadays.
> > >I don't _actually_ want to use swap myself, and having it there only
> > >as the "gold-standard" at the back of the IOU seems the best use.

> > On the contrary - reserving an extra 8Mb of swap per process would

> I replied to your privately already. I don't know how you get this
> idea. It's easy to show that no process can go OOM on stack if every
> process has backing reserved to take its stack pages when they have
> to be taken out of ram for whatever reason.
>
> > CAUSE further OOM problems. You would still run OOM, it would just

OK, again, slowly this time:

You allocate 8Mb for stack for each process on your system (here, a very
underworked workstation, 88 processes right now). That means some 800Mb of
space that is reserved. Add the potential size of the processes data areas
themselves, say some other 800Mb, and this machine can't handle the load: I
has 128Mb RAM + 128Mb swap. With your scheme it won't even be able to
finish booting before going OOM. Forget about minor jobs such as compiling
a kernel or (horror of horrors) egcs + running its testsuite. Which I do
regularly.

Sure, no process can go OOM. The system goes down in flames way before.

-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viņa del Mar, Chile                               +56 32 672616

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