Since I mentioned TIF_MEMDIE in another thread, I simply can't resist.
Sorry for grunting.
On 06/24, Tetsuo Handa wrote:
>
> --- 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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>