On Tue, 12 Jan 2016, Michal Hocko wrote: > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index abefeeb42504..2b9dc5129a89 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -326,6 +326,17 @@ static struct task_struct *select_bad_process(struct oom_control *oc, > case OOM_SCAN_OK: > break; > }; > + > + /* > + * If we are doing sysrq+f then it doesn't make any sense to > + * check OOM victim or killed task because it might be stuck > + * and unable to terminate while the forced OOM might be the > + * only option left to get the system back to work. > + */ > + if (is_sysrq_oom(oc) && (test_tsk_thread_flag(p, TIF_MEMDIE) || > + fatal_signal_pending(p))) > + continue; > + > points = oom_badness(p, NULL, oc->nodemask, totalpages); > if (!points || points < chosen_points) > continue; I think you can make a case for testing TIF_MEMDIE here since there is no chance of a panic from the sysrq trigger. However, I'm not convinced that checking fatal_signal_pending() is appropriate. I think it would be better for sysrq+f to first select a process with fatal_signal_pending() set so it silently gets access to memory reserves and then a second sysrq+f to choose a different process, if necessary, because of TIF_MEMDIE. -- 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>