From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934650AbcIVPGr (ORCPT ); Thu, 22 Sep 2016 11:06:47 -0400 Received: from mx2.suse.de ([195.135.220.15]:42934 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933098AbcIVPGq (ORCPT ); Thu, 22 Sep 2016 11:06:46 -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: <1f47ebe3-61bc-ba8a-defb-9fd8e78614d7@suse.cz> Date: Thu, 22 Sep 2016 17:06:36 +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? In that case I would also add this for consistency? ----8<---- >>From a7921e57ba1189b9c08fc4879358a908c390e47c Mon Sep 17 00:00:00 2001 From: Vlastimil Babka Date: Thu, 22 Sep 2016 17:02:37 +0200 Subject: [PATCH] mm, page_alloc: pull no_progress_loops update to should_reclaim_retry() The should_reclaim_retry() makes decisions based on no_progress_loops, so it makes sense to also update the counter there. It will be also consistent with should_compact_retry() and compaction_retries. No functional change. Signed-off-by: Vlastimil Babka --- mm/page_alloc.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 582820080601..a01359ab3ed6 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3401,16 +3401,26 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask) static inline bool should_reclaim_retry(gfp_t gfp_mask, unsigned order, struct alloc_context *ac, int alloc_flags, - bool did_some_progress, int no_progress_loops) + bool did_some_progress, int *no_progress_loops) { struct zone *zone; struct zoneref *z; /* + * Costly allocations might have made a progress but this doesn't mean + * their order will become available due to high fragmentation so + * always increment the no progress counter for them + */ + if (did_some_progress && order <= PAGE_ALLOC_COSTLY_ORDER) + no_progress_loops = 0; + else + no_progress_loops++; + + /* * Make sure we converge to OOM if we cannot make any progress * several times in the row. */ - if (no_progress_loops > MAX_RECLAIM_RETRIES) + if (*no_progress_loops > MAX_RECLAIM_RETRIES) return false; /* @@ -3425,7 +3435,7 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order, unsigned long reclaimable; available = reclaimable = zone_reclaimable_pages(zone); - available -= DIV_ROUND_UP(no_progress_loops * available, + available -= DIV_ROUND_UP((*no_progress_loops) * available, MAX_RECLAIM_RETRIES); available += zone_page_state_snapshot(zone, NR_FREE_PAGES); @@ -3641,18 +3651,8 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT)) goto nopage; - /* - * Costly allocations might have made a progress but this doesn't mean - * their order will become available due to high fragmentation so - * always increment the no progress counter for them - */ - if (did_some_progress && order <= PAGE_ALLOC_COSTLY_ORDER) - no_progress_loops = 0; - else - no_progress_loops++; - if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags, - did_some_progress > 0, no_progress_loops)) + did_some_progress > 0, &no_progress_loops)) goto retry; /* -- 2.10.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id 4672E6B0276 for ; Thu, 22 Sep 2016 11:06:46 -0400 (EDT) Received: by mail-wm0-f72.google.com with SMTP id b130so74067133wmc.2 for ; Thu, 22 Sep 2016 08:06:46 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id h79si22110487wme.119.2016.09.22.08.06.44 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 22 Sep 2016 08:06:45 -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: <1f47ebe3-61bc-ba8a-defb-9fd8e78614d7@suse.cz> Date: Thu, 22 Sep 2016 17:06:36 +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? In that case I would also add this for consistency? ----8<----