Re: [PATCH] mm,oom: use per signal_struct flag rather than clear TIF_MEMDIE
From: Oleg Nesterov <oleg@redhat.com>
Date: 2016-06-24 21:55:48
Since I mentioned TIF_MEMDIE in another thread, I simply can't resist. Sorry for grunting. On 06/24, Tetsuo Handa wrote:
quoted hunk ↗ jump to hunk
--- a/include/linux/sched.h +++ b/include/linux/sched.h@@ -801,6 +801,7 @@ struct signal_struct { * oom */ bool oom_flag_origin; + bool oom_ignore_victims; /* Ignore oom_victims value */ short oom_score_adj; /* OOM kill score adjustment */ short oom_score_adj_min; /* OOM kill score adjustment min value. * Only settable by CAP_SYS_RESOURCE. */
Yet another kludge to fix yet another problem with TIF_MEMDIE. Not to mention that that wh Can't we state the fact TIF_MEMDIE is just broken? The very idea imo. I am starting to seriously think we should kill this flag, fix the compilation errors, remove the dead code (including the oom_victims logic), and then try to add something else. Say, even MMF_MEMDIE looks better although I understand it is not that simple. Just one question. Why do we need this bit outside of oom-kill.c? It affects page_alloc.c and this probably makes sense. But who get this flag when we decide to kill the memory hog? A random thread foung by find_lock_task_mm(), iow a random thread with ->mm != NULL, likely the group leader. This simply can not be right no matter what. And in any case I don't understand this patch but I have to admit that I failed to force myself to read the changelog and the actual change ;) In any case I agree that we should not set MMF_MEMDIE if ->mm == NULL, and if we ensure this then I do not understand why we can't rely on MMF_OOM_REAPED. Ignoring the obvious races, if ->oom_victims != 0 then find_lock_task_mm() should succed. Oleg. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>