Michal Hocko wrote: > The first obvious one is when the oom victim clears its mm and gets > stuck later on. oom_reaper would back of on find_lock_task_mm returning > NULL. We can safely try to clear TIF_MEMDIE in this case because such a > task would be ignored by the oom killer anyway. The flag would be > cleared by that time already most of the time anyway. I didn't understand what this wants to tell. The OOM victim will clear TIF_MEMDIE as soon as it sets current->mm = NULL. Even if the oom victim clears its mm and gets stuck later on (e.g. at exit_task_work()), TIF_MEMDIE was already cleared by that moment by the OOM victim. > > The less obvious one is when the oom reaper fails due to mmap_sem > contention. Even if we clear TIF_MEMDIE for this task then it is not > very likely that we would select another task too easily because > we haven't reaped the last victim and so it would be still the #1 > candidate. There is a rare race condition possible when the current > victim terminates before the next select_bad_process but considering > that oom_reap_task had retried several times before giving up then > this sounds like a borderline thing. Is it helpful? Allowing the OOM killer to select the same thread again simply makes the kernel log buffer flooded with the OOM kill messages. I think we should not allow the OOM killer to select the same thread again by e.g. doing tsk->signal->oom_score_adj = OOM_SCORE_ADJ_MIN regardless of whether reaping that thread's memory succeeded or not. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>