From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757482AbcIVO75 (ORCPT ); Thu, 22 Sep 2016 10:59:57 -0400 Received: from mx2.suse.de ([195.135.220.15]:41928 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753112AbcIVO74 (ORCPT ); Thu, 22 Sep 2016 10:59:56 -0400 Subject: Re: [PATCH 2/4] mm, compaction: more reliably increase direct compaction priority To: Michal Hocko References: <20160906135258.18335-1-vbabka@suse.cz> <20160906135258.18335-3-vbabka@suse.cz> <20160921171348.GF24210@dhcp22.suse.cz> <20160922140821.GG11875@dhcp22.suse.cz> <20160922145237.GH11875@dhcp22.suse.cz> Cc: Andrew Morton , Arkadiusz Miskiewicz , Ralf-Peter Rohbeck , Olaf Hering , linux-kernel@vger.kernel.org, Linus Torvalds , linux-mm@kvack.org, Mel Gorman , Joonsoo Kim , David Rientjes , Rik van Riel From: Vlastimil Babka Message-ID: Date: Thu, 22 Sep 2016 16:59:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160922145237.GH11875@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/22/2016 04:52 PM, Michal Hocko wrote: > On Thu 22-09-16 16:08:21, Michal Hocko wrote: >> On Thu 22-09-16 14:51:48, Vlastimil Babka wrote: >> > >From 465e1bd61b7a6d6901a44f09b1a76514dbc220fa Mon Sep 17 00:00:00 2001 >> > From: Vlastimil Babka >> > Date: Thu, 22 Sep 2016 13:54:32 +0200 >> > Subject: [PATCH] mm, compaction: more reliably increase direct compaction >> > priority-fix >> > >> > When increasing the compaction priority, also reset retries. Otherwise we can >> > consume all retries on the lower priorities. >> >> OK, this is an improvement. I am just thinking that we might want to >> pull >> if (order && compaction_made_progress(compact_result)) >> compaction_retries++; >> >> into should_compact_retry as well. I've had it there originally because >> it was in line with no_progress_loops but now that we have compaction >> priorities it would fit into retry logic better. As a plus it would >> count only those compaction rounds where we we didn't have to rely on > did that should be > >> the compaction retry logic. What do you think? Makes sense. -----8<----- >>From f775ec4be05a21c78a718a382c13132dedd5e2a4 Mon Sep 17 00:00:00 2001 From: Vlastimil Babka Date: Thu, 22 Sep 2016 13:54:32 +0200 Subject: [PATCH] mm, compaction: more reliably increase direct compaction priority-fix-v2 When increasing the compaction priority, also reset retries. Otherwise we can consume all retries on the lower priorities. Also pull the retries increment into should_compact_retry() so it counts only the rounds where we actually rely on it. Suggested-by: Michal Hocko Signed-off-by: Vlastimil Babka Acked-by: Michal Hocko --- mm/page_alloc.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index f8bed910e3cf..582820080601 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3162,13 +3162,16 @@ static inline bool should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, enum compact_result compact_result, enum compact_priority *compact_priority, - int compaction_retries) + int *compaction_retries) { int max_retries = MAX_COMPACT_RETRIES; if (!order) return false; + if (compaction_made_progress(compact_result)) + (*compaction_retries)++; + /* * compaction considers all the zone as desperately out of memory * so it doesn't really make much sense to retry except when the @@ -3196,16 +3199,17 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, */ if (order > PAGE_ALLOC_COSTLY_ORDER) max_retries /= 4; - if (compaction_retries <= max_retries) + if (*compaction_retries <= max_retries) return true; /* - * Make sure there is at least one attempt at the highest priority - * if we exhausted all retries at the lower priorities + * Make sure there are attempts at the highest priority if we exhausted + * all retries or failed at the lower priorities. */ check_priority: if (*compact_priority > MIN_COMPACT_PRIORITY) { (*compact_priority)--; + *compaction_retries = 0; return true; } return false; @@ -3224,7 +3228,7 @@ static inline bool should_compact_retry(struct alloc_context *ac, unsigned int order, int alloc_flags, enum compact_result compact_result, enum compact_priority *compact_priority, - int compaction_retries) + int *compaction_retries) { struct zone *zone; struct zoneref *z; @@ -3626,9 +3630,6 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, if (page) goto got_pg; - if (order && compaction_made_progress(compact_result)) - compaction_retries++; - /* Do not loop if specifically requested */ if (gfp_mask & __GFP_NORETRY) goto nopage; @@ -3663,7 +3664,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, if (did_some_progress > 0 && should_compact_retry(ac, order, alloc_flags, compact_result, &compact_priority, - compaction_retries)) + &compaction_retries)) goto retry; /* Reclaim has failed us, start killing things */ -- 2.10.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 095F76B026F for ; Thu, 22 Sep 2016 10:59:57 -0400 (EDT) Received: by mail-wm0-f70.google.com with SMTP id w84so73422281wmg.1 for ; Thu, 22 Sep 2016 07:59:56 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id x188si2870857wmx.16.2016.09.22.07.59.55 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 22 Sep 2016 07:59:55 -0700 (PDT) Subject: Re: [PATCH 2/4] mm, compaction: more reliably increase direct compaction priority References: <20160906135258.18335-1-vbabka@suse.cz> <20160906135258.18335-3-vbabka@suse.cz> <20160921171348.GF24210@dhcp22.suse.cz> <20160922140821.GG11875@dhcp22.suse.cz> <20160922145237.GH11875@dhcp22.suse.cz> From: Vlastimil Babka Message-ID: Date: Thu, 22 Sep 2016 16:59:51 +0200 MIME-Version: 1.0 In-Reply-To: <20160922145237.GH11875@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Andrew Morton , Arkadiusz Miskiewicz , Ralf-Peter Rohbeck , Olaf Hering , linux-kernel@vger.kernel.org, Linus Torvalds , linux-mm@kvack.org, Mel Gorman , Joonsoo Kim , David Rientjes , Rik van Riel On 09/22/2016 04:52 PM, Michal Hocko wrote: > On Thu 22-09-16 16:08:21, Michal Hocko wrote: >> On Thu 22-09-16 14:51:48, Vlastimil Babka wrote: >> > >From 465e1bd61b7a6d6901a44f09b1a76514dbc220fa Mon Sep 17 00:00:00 2001 >> > From: Vlastimil Babka >> > Date: Thu, 22 Sep 2016 13:54:32 +0200 >> > Subject: [PATCH] mm, compaction: more reliably increase direct compaction >> > priority-fix >> > >> > When increasing the compaction priority, also reset retries. Otherwise we can >> > consume all retries on the lower priorities. >> >> OK, this is an improvement. I am just thinking that we might want to >> pull >> if (order && compaction_made_progress(compact_result)) >> compaction_retries++; >> >> into should_compact_retry as well. I've had it there originally because >> it was in line with no_progress_loops but now that we have compaction >> priorities it would fit into retry logic better. As a plus it would >> count only those compaction rounds where we we didn't have to rely on > did that should be > >> the compaction retry logic. What do you think? Makes sense. -----8<-----