From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753160AbcHPGbR (ORCPT ); Tue, 16 Aug 2016 02:31:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:46141 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751006AbcHPGbR (ORCPT ); Tue, 16 Aug 2016 02:31:17 -0400 Subject: Re: [PATCH v6 06/11] mm, compaction: more reliably increase direct compaction priority To: Joonsoo Kim References: <20160810091226.6709-1-vbabka@suse.cz> <20160810091226.6709-7-vbabka@suse.cz> <20160816060737.GC17448@js1304-P5Q-DELUXE> Cc: Andrew Morton , Michal Hocko , Mel Gorman , David Rientjes , Rik van Riel , linux-mm@kvack.org, linux-kernel@vger.kernel.org From: Vlastimil Babka Message-ID: Date: Tue, 16 Aug 2016 08:31:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <20160816060737.GC17448@js1304-P5Q-DELUXE> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/16/2016 08:07 AM, Joonsoo Kim wrote: >> Signed-off-by: Vlastimil Babka >> --- >> mm/page_alloc.c | 18 +++++++++++------- >> 1 file changed, 11 insertions(+), 7 deletions(-) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index fb975cec3518..b28517b918b0 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -3155,13 +3155,8 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, >> * so it doesn't really make much sense to retry except when the >> * failure could be caused by insufficient priority >> */ >> - if (compaction_failed(compact_result)) { >> - if (*compact_priority > MIN_COMPACT_PRIORITY) { >> - (*compact_priority)--; >> - return true; >> - } >> - return false; >> - } >> + if (compaction_failed(compact_result)) >> + goto check_priority; >> >> /* >> * make sure the compaction wasn't deferred or didn't bail out early >> @@ -3185,6 +3180,15 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, >> 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 >> + */ >> +check_priority: >> + if (*compact_priority > MIN_COMPACT_PRIORITY) { >> + (*compact_priority)--; >> + return true; >> + } >> return false; > > The only difference that this patch makes is increasing priority when > COMPACT_PARTIAL(COMPACTION_SUCCESS) returns. In that case, we can Hm it's true that I adjusted this patch from the previous version, before realizing that PARTIAL is now SUCCESS. > usually allocate high-order freepage so we would not enter here. Am I > missing something? Is it really needed behaviour change? It will likely be rare when this triggers, when compaction success doesn't lead to allocation success due to parallel allocation activity. > Thanks. >