Re: Avoiding OOM on overcommit...?

From: Horst von Brand (vonbrand@sleipnir.valparaiso.cl)
Date: Thu Mar 30 2000 - 05:33:48 EST


"Peter T. Breuer" <ptb@it.uc3m.es> said:
[...]

> I'd start init and cron as secure jobs. I can't think of anything else
> that needs to be secure. Practically speaking, init in itself is enough
> (I run cron from init, and cron checks and revives other daemons).

It is much easier to get the OOM-killer to respect them, for even better
results: if init suddenly needs 12Mb of stack, it will go on. Rik's patch
(at least tries hard to) do so.

[...]

> I.e. you'd only get thrashing if every process on your system was
> running as a secure process, and ram+swap were full. Just like now.
> Indeed, the only change I propose is an accounting change and the only
> effect it has is in saying when certain processes can _start up_ (or if
> they can). So it has no effect on the characteristics of the system
> with respect to those processes already running. Your system would
> behave just as it does now. It would just be more secure :-).

Thrasing means memory is overused; as the assurances won't be used most of
the time, no thrashing would happen because of them. Thrashing will be
harder to go into, as the system will probably go down before anyway for
lack of memory.

And again, please: OOM, thrashing and such are extreme sitations. The only
objective here is to try to avoid them (all the "no overcommitmemt" ideas
make OOM worse, not better), or get the system to behave halfway sanely or
at least go down with some dignity if it completely runs out of resources.
You _don't_ want to run your system OOM or thrasing. Just try it on for
size sometime.

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