Messages in this thread | | On Sun, 31 Jan 2010, Vedran Furac wrote:
> > You snipped the code segment where I demonstrated that the selected task > > for oom kill is not necessarily the one chosen to die: if there is a child > > with disjoint memory that is killable, it will be selected instead. If > > Xorg or sshd is being chosen for kill, then you should investigate why > > that is, but there is nothing random about how the oom killer chooses > > tasks to kill. > > I know that it isn't random, but it sure looks like that to the end user > and I use it to emphasize the problem. And about me investigating, that > simply not possible as I am not a kernel hacker who understands the code > beyond the syntax level. I can only point to the problem in hope that > someone will fix it. >
Disregarding the opportunity that userspace has to influence the oom killer's selection for a moment, it really tends to favor killing tasks that are the largest in size. Tasks that typically get the highest badness score are those that have the highest mm->total_vm, it's that simple. There are definitely cornercases where the first generation children have a strong influence, but they are often killed either as a result of themselves being a thread group leader with seperate memory from the parent or as the result of the oom killer killing a task with seperate memory before the selected task. It's completely natural for the oom killer to select bash, for example, when in actuality it will kill a memory leaker that has a high badness score as a result of the logic in oom_kill_process().
If you have specific logs that you'd like to show, please enable /proc/sys/vm/oom_dump_tasks and respond with them in another message with that data inline.
| |