On Wed, Mar 25, 2015 at 06:01:48PM +0100, Vlastimil Babka wrote: > On 03/25/2015 03:15 PM, Tetsuo Handa wrote: > >Johannes Weiner wrote: > >>diff --git a/mm/oom_kill.c b/mm/oom_kill.c > >>index 5cfda39b3268..e066ac7353a4 100644 > >>--- a/mm/oom_kill.c > >>+++ b/mm/oom_kill.c > >>@@ -711,12 +711,15 @@ bool out_of_memory(struct zonelist *zonelist, gfp_t > >>gfp_mask, > >> killed = 1; > >> } > >> out: > >>+ if (test_thread_flag(TIF_MEMDIE)) > >>+ return true; > >> /* > >>- * Give the killed threads a good chance of exiting before trying to > >>- * allocate memory again. > >>+ * Wait for any outstanding OOM victims to die. In rare cases > >>+ * victims can get stuck behind the allocating tasks, so the > >>+ * wait needs to be bounded. It's crude alright, but cheaper > >>+ * than keeping a global dependency tree between all tasks. > >> */ > >>- if (killed) > >>- schedule_timeout_killable(1); > >>+ wait_event_timeout(oom_victims_wait, !atomic_read(&oom_victims), HZ); > >> > >> return true; > >> } > > > >out_of_memory() returning true with bounded wait effectively means that > >wait forever without choosing subsequent OOM victims when first OOM victim > >failed to die. The system will lock up, won't it? > > And after patch 12, does this mean that you may not be waiting long enough > for the victim to die, before you fail the allocation, prematurely? I can > imagine there would be situations where the victim is not deadlocked, but > still take more than HZ to finish, no?
Arguably it should be reasonable to fail allocations once the OOM victim is stuck for over a second and the OOM reserves have been depleted. On the other hand, we don't need to play it that tight, because that timeout is only targetted for the victim-blocked-on-alloc situations which aren't all that common. Something like 5 seconds should still be okay. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
