One person pointed out (rightly so) that this patch might end up killing a Oracle process for example since it occupies more than 60% memory - which is not good. While that may be case for a server, I think for a desktop this patch is right - it allows the user to gain control on the machine which has gone OOM.
> Thank you for the patch, I'm in agreement with the idea, and I'll give > it a try after I look at the code a bit. The current code frequently > seems bit... non-deterministic. > > -- > -bill davidsen ([EMAIL PROTECTED]) > "The secret to procrastination is to put things off until the > last possible moment - but no longer" -me I think oom_kill.c needs more intelligence and customizability. It should evaluate the per process rate of memory allocation for example. With that, it can determine if a process has had a steady VM size and give it less badness since there is a good possibility that some other process(es) might have gone bad doing fork bombs or leaking memory. In short less badness for processes behaving well for a long time and not taking all the memory and not asking for more. OTOH we need more configurability - Desktop settings might depict A)Dont kill X B) Don't kill KDE for example. Then OOM killer then can spare those processes to see if killing other processes is going to benefit. (If X / KDE went bad and gobbled up memory, may be it might still kill it - again rate of allocation matters.) Server admins might specify no killing of a database process until unless it is occupying all memory etc.. Parag > Parag Warudkar wrote: > > oom_kill.c misses very obvious targets - For example, a process occupying > > > 80% memory, not superuser and not having hardware access gets ignored by > > it. > > Logically, such a process, if killed , is going to make things return to > > normal thereby eliminating the need for oom killer to further scan for more > > processes. > > > > This patch calculates the approximate integer percentage of memory occupied > > by > > the process by looking at num_physpages and p->mm->total_vm. If this > > process > > is not super user and doesn't have hardware access, and the percentage of > > occupied memory is more than 60%, it immediately selects this process for > > killing by returning unusually high points from badness(). > > > > Without this patch, when KDevelop running as non root user gobbles up 90% > > memory, the OOM killer kills many other irrelevant processes but not > > KDevelop > > And machine never recovers.. (Pls see LKML for my previous message with > > subject "2.6.11-rc4 OOM Killer - Kill the Innocent".) > > > > With this patch OOM killer immediately kills kdevelop and machine recovers. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
