Michal Hocko wrote: > I have seen that patch. I didn't get to review it properly yet as I am > still travelling. From a quick view I think it is conflating two things > together. I could see arguments for the panic part but I do not consider > the move-to-kill-another timeout as justified. I would have to see a > clear indication this is actually useful for real life usecases. You admit that it is possible that the TIF_MEMDIE thread is blocked at unkillable wait (due to memory allocation requests by somebody else) but the OOM reaper cannot reap the victim's memory (due to holding the mmap_sem for write), don't you? Then, I think this patch makes little sense unless accompanied with the move-to-kill-another timeout. If the OOM reaper failed to reap the victim's memory, the OOM reaper simply clears TIF_MEMDIE from the victim thread. But since nothing has changed (i.e. the victim continues waiting, and the victim's memory is not reclaimed, and the victim's oom_score_adj is not updated to OOM_SCORE_ADJ_MIN), the OOM killer will select that same victim again. This forms an infinite loop. You will want to call panic() as soon as the OOM reaper failed to reap the victim's memory (than waiting for the panic timeout). For both system operators at customer's companies and staffs at support center, avoiding hangup (due to OOM livelock) and panic (due to the OOM panic timeout) eliminates a lot of overhead. This is a practical benefit for them. I also think that the purpose of killing only one task at a time than calling panic() is to save as much work as possible. Therefore, I can't understand why you don't think that killing only another task via the move-to-kill-another timeout is a useful real life usecase. panic on timeout is a practical benefit for you, but giving several chances on timeout is a practical benefit for someone you don't know. -- 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>