From mboxrd@z Thu Jan 1 00:00:00 1970 From: Karol Lewandowski Subject: [PATCH] SLUB: Don't drop __GFP_NOFAIL completely from allocate_slab() (was: Re: [Bug #14265] ifconfig: page allocation failure. order:5,ode:0x8020 w/ e100) Date: Wed, 21 Oct 2009 22:04:42 +0200 Message-ID: <20091021200442.GA2987@bizet.domek.prywatny> References: <3onW63eFtRF.A.xXH.oMTxKB@chimera> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=ZWbQp2aF9waZ1qiBc0ciSxP+KLslizGnKfCwvDt/wow=; b=p1jHEZigfwQt7cRQ+L+xqtpdtFyWp7F7bcoGKTad1A0W6pldTz8cIISX3NgptB7oAV NniUPbirIf1+R1dGrxay+w+SL09cyOZOkDPB3vKrGi5WrzgUtWkSMpr8UVyimOP6HQX+ LeeGL2ndWJlIL5+cNEAt9ihFSNVtdCpDr1Vzg= Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Rafael J. Wysocki" Cc: Linux Kernel Mailing List , Kernel Testers List , Karol Lewandowski , Mel Gorman , Frans Pop , Pekka Enberg , David Rientjes , KOSAKI Motohiro , Reinette Chatre , Bartlomiej Zolnierkiewicz , Mohamed Abbas , "John W. Linville" , linux-mm@kvack.org, jens.axboe@oracle.com, Tobias Oetiker On Thu, Oct 01, 2009 at 09:56:04PM +0200, Rafael J. Wysocki wrote: > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14265 > Subject : ifconfig: page allocation failure. order:5, mode:0x8020 w/ e100 > Submitter : Karol Lewandowski > Date : 2009-09-15 12:05 (17 days old) > References : http://marc.info/?l=linux-kernel&m=125301636509517&w=4 Guys, could anyone check if patch below helps? I think I've finally found culprit of all allocation failures (but I might be wrong too... ;-) Thanks. commit d6849591e042bceb66f1b4513a1df6740d2ad762 Author: Karol Lewandowski Date: Wed Oct 21 21:01:20 2009 +0200 SLUB: Don't drop __GFP_NOFAIL completely from allocate_slab() Commit ba52270d18fb17ce2cf176b35419dab1e43fe4a3 unconditionally cleared __GFP_NOFAIL flag on all allocations. Preserve this flag on second attempt to allocate page (with possibly decreased order). This should help with bugs #14265, #14141 and similar. Signed-off-by: Karol Lewandowski diff --git a/mm/slub.c b/mm/slub.c index b627675..ac5db65 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1084,7 +1084,7 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node) { struct page *page; struct kmem_cache_order_objects oo = s->oo; - gfp_t alloc_gfp; + gfp_t alloc_gfp, nofail; flags |= s->allocflags; @@ -1092,6 +1092,7 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node) * Let the initial higher-order allocation fail under memory pressure * so we fall-back to the minimum order allocation. */ + nofail = flags & __GFP_NOFAIL; alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL; page = alloc_slab_page(alloc_gfp, node, oo); @@ -1100,8 +1101,10 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node) /* * Allocation may have failed due to fragmentation. * Try a lower order alloc if possible + * + * Preserve __GFP_NOFAIL flag if previous allocation failed. */ - page = alloc_slab_page(flags, node, oo); + page = alloc_slab_page(flags | nofail, node, oo); if (!page) return NULL; -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org