On Thu, 18 Feb 2016, Michal Hocko wrote: > > Anyway, this is NACK'd since task->signal->oom_score_adj is checked under > > task_lock() for threads with memory attached, that's the purpose of > > finding the correct thread in oom_badness() and taking task_lock(). We > > aren't going to duplicate logic in several functions that all do the same > > thing. > > Is the task_lock really necessary, though? E.g. oom_task_origin() > doesn't seem to depend on it for task->signal safety. If you are > referring to races with changing oom_score_adj does such a race matter > at all? > oom_badness() ranges from 0 (don't kill) to 1000 (please kill). It factors in the setting of /proc/self/oom_score_adj to change that value. That is where OOM_SCORE_ADJ_MIN is enforced. It is also needed in oom_badness() to determine whether a child process should be sacrificed for its parent. We don't add duplicate logic everywhere if you want the code to be maintainable; the only exception would be for performance critical code which the oom killer most certainly is not. I'm simply not entertaining any patch to the oom killer that duplicates code everywhere, increases its complexity, makes it grow in text size, and makes it more difficult to maintain. -- 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>