Re: [PATCH] strict VM overcommit for stock 2.4

[Szakacsits Szabolcs]

On 18 Jul 2002, Robert Love wrote:
> Btw, without this it is possible to OOM any machine.  OOM is a
> by-product of allowing overcommit and poor accounting (and perhaps
> poor software/users), not an incorrectly configured machine.

Very well said, now I try to explain again what's missing from the
patch: livelock is a by-product of allowing strict VM overcommit and
poor accounting (and perhaps poor software/users), not an incorrectly
configured machine.

So where is the solution for "poor accounting (and perhaps poor
software/users), not an incorrectly configured machine" users? These
are part of life and please don't claim all your work was perfect at
first shoot and automatically adapted in all changing environments
whitout ever touching it again on a general purpose system. Even if
it would be true, not everybody supergenius.

So which one is better? OOM killer that considers root owned processes
to make his decision or strict VM overcommit that doesn't distinguish
root and non-root users and potentially will livelock [if you don't
have some custom solution, like "trigger OOM handler through sysrq"
patch posted here a year ago].

For embedded systems the later, for general purpose systems the first
is better in average however this is not linux-embedded and later on
people using Linux for general purpose could get the impression strict
VM overcommit is useful for them and potentially would end up in a
worse situation than without it (see my example sent, default kernel
OOM killed the bad process, with your patch reset the box).

*However* distinguishing root and non-root users also in strict VM
overcommit would make a significant difference for general purpose
systems, this was always my point.

Can you see the non-orthogonality now?

	Szaka