OOM-killer prevention for master kdeinit process

[Chase Venters]

On Wed, 2 Aug 2006, Arnold Krille wrote:

> Am Mittwoch, 2. August 2006 17:07 schrieb Lubos Lunak:
>> On Wednesday 02 August 2006 15:59, Robert Knight wrote:
>>> What on earth is using up that 1GB?
>>  Whatever happens to fill it up, e.g. accidental parallel linking when
>> building kdebase is good for that. But that's not the point at all, the
>> problem is that instead of killing whatever is responsible for running
>> short on memory it instead kills kdeinit.
>
> Aren't there different behaviors to select upon kernel-compilation? Afaik
> there is also one mode to kill the app that wants more space...

Well, I don't know if it's a CONFIG_, but there is control over VM 
overcommit in /proc.

For the record, I think VM overcommit is brilliant. It's fantastic for 
certain loads (for example, an Apache prefork server with mod_perl). But I 
wonder if anyone has ever done any measurement on the Linux desktop? It 
may be that VM overcommit is something worth just turning off on the 
desktop (now, KDE shouldn't dictate that of course, that would be a great 
thing for Kubuntu et. al. to consider, though).

(Really, overcommit should be conservative enough to rarely let the OOM 
killer go running around, but in all practicality I've had a kicker leak 
bug for a while and if I don't notice it for a few days, the OOM killer 
will eventually start looking for blood [though usually the system 
starts getting way slow for a while before that happens, so I notice and 
kill it myself].)

> BTW: I never had any luck with this method either. Most times the memory was
> filled by some recursive function (for university) but than X demanded more
> space and got killed therefor. Which in turn left me with plenty of memory as
> all apps where children inside the X-session.
>
> Arnold

Thanks,
Chase