On Tue 12-01-16 16:41:50, David Rientjes wrote: > 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. My thinking was that such a process would get TIF_MEMDIE if it hits the OOM from the allocator. > 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. The disadvantage of this approach is that sysrq+f might silently be ignored and the administrator doesn't have any signal about that. IMHO sysrq+f would be much better defined if it _always_ selected and killed a task. After all it is an explicit administrator action. -- Michal Hocko SUSE Labs -- 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>