Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753340AbZGPLDb (ORCPT ); Thu, 16 Jul 2009 07:03:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752374AbZGPLDb (ORCPT ); Thu, 16 Jul 2009 07:03:31 -0400 Received: from gir.skynet.ie ([193.1.99.77]:41794 "EHLO gir.skynet.ie" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752245AbZGPLDa (ORCPT ); Thu, 16 Jul 2009 07:03:30 -0400 Date: Thu, 16 Jul 2009 12:03:29 +0100 From: Mel Gorman To: David Rientjes Cc: Andrew Morton , Nick Piggin , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] page-allocator: Ensure that processes that have been OOM killed exit the page allocator (resend) Message-ID: <20090716110328.GB22499@csn.ul.ie> References: <20090715104944.GC9267@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2515 Lines: 72 On Wed, Jul 15, 2009 at 01:29:33PM -0700, David Rientjes wrote: > On Wed, 15 Jul 2009, Mel Gorman wrote: > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index f8902e7..5c98d02 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -1547,6 +1547,14 @@ should_alloc_retry(gfp_t gfp_mask, unsigned int order, > > if (gfp_mask & __GFP_NORETRY) > > return 0; > > > > + /* Do not loop if OOM-killed unless __GFP_NOFAIL is specified */ > > + if (test_thread_flag(TIF_MEMDIE)) { > > + if (gfp_mask & __GFP_NOFAIL) > > + WARN(1, "Potential infinite loop with __GFP_NOFAIL"); > > + else > > + return 0; > > + } > > + > > /* > > * In this implementation, order <= PAGE_ALLOC_COSTLY_ORDER > > * means __GFP_NOFAIL, but that may not be true in other > > > > This only works for GFP_ATOMIC since the next iteration of the page > allocator will (probably) fail reclaim and simply invoke the oom killer > again, GFP_ATOMIC should not be calling the OOM killer. It has already exited. Immeditely after an OOM kill, I would expect the allocation to succeed. However, in the event that the task selected for OOM killing is the current one and no other task exits, it could loop. > which will notice current has TIF_MEMDIE set and choose to do > nothing, at which time the allocator simply loops again. > So, we should unconditionally check if we should loop again whether we have OOM killed or not which the following should do. ==== CUT HERE ==== page-allocator: Check after an OOM kill if the allocator should loop Currently, the allocator loops unconditionally after an OOM kill on the assumption that the allocation will succeed. However, if the task selected for OOM-kill is the current task, it could in theory loop forever and always entering the OOM killer. This patch checks as normal after an OOM kill if the allocator should loop again. Signed-off-by: Mel Gorman -- mm/page_alloc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 4b8552e..b381a6b 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1830,8 +1830,6 @@ rebalance: if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_NOFAIL)) goto nopage; - - goto restart; } } -- 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/