OOM-killer prevention for master kdeinit process

[Chase Venters]

On Thu, 3 Aug 2006, Josef Weidendorfer wrote:

> On Wednesday 02 August 2006 15:09, Lubos Lunak wrote:
>> ls /proc/*/oom_score | grep -v self | sed 's/\(.*\)\/\(.*\)/echo -n "\1 ";
>> echo -n "`cat \1\/\2 2>\/dev\/null` "; readlink \1\/exe || echo/'| sh |
>> sort -nr +1
>>
>> That gives lines with </proc/pid> <likelyhood to be oom-killed> <binary>.
>> Run "pstree -p" and compare it with the top of the list. The very first item
>> that's going to be killed when running out of memory is going to be the
>> master kdeinit process, i.e. the tiny thingy that is linked against our basic
>> libraries which we use for launching apps. The reason why it's going to be
>> killed the first is that OOM-killing has some "smart" heuristic that counts
>> also all child processes into parent's score (it's mentioned in the paper)
>
> Hmmm.... just a idea:
> Why is kdeinit not doing 2 forks to get rid of the parent relationship?
> This should help the OOM score a lot, and I see no bad thing in having
> init as parent for most KDE apps. Or am I missing something?

Unless I'm missing something, setsid() > double fork for performance 
reasons.

Now, I haven't looked at kdeinit's code, so I don't know if it actually 
/cares/ about being a pgrp leader over KDE. Thoughts?

> Josef
>

Thanks,
Chase