From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by kanga.kvack.org (Postfix) with ESMTP id DAAAA6B0289 for ; Wed, 18 Nov 2015 08:04:21 -0500 (EST) Received: by wmec201 with SMTP id c201so72057728wme.1 for ; Wed, 18 Nov 2015 05:04:21 -0800 (PST) Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com. [74.125.82.53]) by mx.google.com with ESMTPS id r3si4593190wma.122.2015.11.18.05.04.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2015 05:04:16 -0800 (PST) Received: by wmww144 with SMTP id w144so196195038wmw.1 for ; Wed, 18 Nov 2015 05:04:16 -0800 (PST) From: Michal Hocko Subject: [RFC 3/3] mm: use watermak checks for __GFP_REPEAT high order allocations Date: Wed, 18 Nov 2015 14:04:00 +0100 Message-Id: <1447851840-15640-4-git-send-email-mhocko@kernel.org> In-Reply-To: <1447851840-15640-1-git-send-email-mhocko@kernel.org> References: <1447851840-15640-1-git-send-email-mhocko@kernel.org> Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: Andrew Morton , Linus Torvalds , Mel Gorman , Johannes Weiner , David Rientjes , Tetsuo Handa , Hillf Danton , KAMEZAWA Hiroyuki , Michal Hocko From: Michal Hocko __alloc_pages_slowpath retries costly allocations until at least order worth of pages were reclaimed or the watermark check for at least one zone would succeed after all reclaiming all pages if the reclaim hasn't made any progress. The first condition was added by a41f24ea9fd6 ("page allocator: smarter retry of costly-order allocations) and it assumed that lumpy reclaim could have created a page of the sufficient order. Lumpy reclaim, has been removed quite some time ago so the assumption doesn't hold anymore. It would be more appropriate to check the compaction progress instead but this patch simply removes the check and relies solely on the watermark check. To prevent from too many retries the stall_backoff is not reseted after a reclaim which made progress because we cannot assume it helped high order situation. Signed-off-by: Michal Hocko --- mm/page_alloc.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index e6271bc19e6a..999c8cdbe7b5 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3006,7 +3006,6 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, bool can_direct_reclaim = gfp_mask & __GFP_DIRECT_RECLAIM; struct page *page = NULL; int alloc_flags; - unsigned long pages_reclaimed = 0; unsigned long did_some_progress; enum migrate_mode migration_mode = MIGRATE_ASYNC; bool deferred_compaction = false; @@ -3167,24 +3166,21 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, /* * Do not retry high order allocations unless they are __GFP_REPEAT - * and even then do not retry endlessly unless explicitly told so + * unless explicitly told so. */ - pages_reclaimed += did_some_progress; - if (order > PAGE_ALLOC_COSTLY_ORDER) { - if (!(gfp_mask & __GFP_NOFAIL) && - (!(gfp_mask & __GFP_REPEAT) || pages_reclaimed >= (1< PAGE_ALLOC_COSTLY_ORDER && + !(gfp_mask & (__GFP_REPEAT|__GFP_NOFAIL))) + goto noretry; /* * Be optimistic and consider all pages on reclaimable LRUs as usable * but make sure we converge to OOM if we cannot make any progress after * multiple consecutive failed attempts. + * Costly __GFP_REPEAT allocations might have made a progress but this + * doesn't mean their order will become available due to high fragmentation + * so do not reset the backoff for them */ - if (did_some_progress) + if (did_some_progress && order <= PAGE_ALLOC_COSTLY_ORDER) stall_backoff = 0; else stall_backoff = min(stall_backoff+1, MAX_STALL_BACKOFF); -- 2.6.2 -- 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