Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965611AbbD1NSz (ORCPT ); Tue, 28 Apr 2015 09:18:55 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45553 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965423AbbD1NSx (ORCPT ); Tue, 28 Apr 2015 09:18:53 -0400 Date: Tue, 28 Apr 2015 15:18:50 +0200 From: Michal Hocko To: Johannes Weiner Cc: Andrew Morton , Tetsuo Handa , Andrea Arcangeli , Dave Chinner , David Rientjes , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 8/9] mm: page_alloc: wait for OOM killer progress before retrying Message-ID: <20150428131850.GC2659@dhcp22.suse.cz> References: <1430161555-6058-1-git-send-email-hannes@cmpxchg.org> <1430161555-6058-9-git-send-email-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430161555-6058-9-git-send-email-hannes@cmpxchg.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2139 Lines: 59 On Mon 27-04-15 15:05:54, Johannes Weiner wrote: > There is not much point in rushing back to the freelists and burning > CPU cycles in direct reclaim when somebody else is in the process of > OOM killing, or right after issuing a kill ourselves, because it could > take some time for the OOM victim to release memory. > > This is a very cold error path, so there is not much hurry. Use the > OOM victim waitqueue to wait for victims to actually exit, which is a > solid signal that the memory pinned by those tasks has been released. > > Signed-off-by: Johannes Weiner Looks good to me. One minor thing/suggestion below. Acked-by: Michal Hocko > --- > mm/oom_kill.c | 11 +++++++---- > mm/page_alloc.c | 43 ++++++++++++++++++++++++++----------------- > 2 files changed, 33 insertions(+), 21 deletions(-) > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index 5cfda39..823f87e 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), 5*HZ); WARN(!wait_event_timeout(...), "OOM victim has hard time to finish. OOM deadlock?") or something along those lines? It would tell the admin that something fishy is going here. > > return true; > } [...] -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/