From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751972AbcEJMzT (ORCPT ); Tue, 10 May 2016 08:55:19 -0400 Received: from mx2.suse.de ([195.135.220.15]:44601 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751699AbcEJMzS (ORCPT ); Tue, 10 May 2016 08:55:18 -0400 Subject: Re: [RFC 12/13] mm, compaction: more reliably increase direct compaction priority To: Michal Hocko References: <1462865763-22084-1-git-send-email-vbabka@suse.cz> <1462865763-22084-13-git-send-email-vbabka@suse.cz> Cc: linux-mm@kvack.org, Andrew Morton , Joonsoo Kim , Rik van Riel , David Rientjes , Mel Gorman , Johannes Weiner , Tetsuo Handa , linux-kernel@vger.kernel.org, Linus Torvalds From: Vlastimil Babka Message-ID: <5731DA32.7090707@suse.cz> Date: Tue, 10 May 2016 14:55:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1462865763-22084-13-git-send-email-vbabka@suse.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/10/2016 09:36 AM, Vlastimil Babka wrote: > /* > - * compaction considers all the zone as desperately out of memory > - * so it doesn't really make much sense to retry except when the > - * failure could be caused by insufficient priority > + * Compaction backed off due to watermark checks for order-0 > + * so the regular reclaim has to try harder and reclaim something > + * Retry only if it looks like reclaim might have a chance. > */ > - if (compaction_failed(compact_result)) { > - if (*compact_priority > 0) { > - (*compact_priority)--; > - return true; > - } > - return false; > - } Oops, looks like my editing resulted in compaction_failed() check to be removed completely, which wasn't intentional and can lead to infinite loops. This should be added on top. ----8<---- >>From 59a2b38689aa451f661c964dc9bfb990736ad92d Mon Sep 17 00:00:00 2001 From: Vlastimil Babka Date: Tue, 10 May 2016 14:51:03 +0200 Subject: [PATCH 15/15] fixup! mm, compaction: more reliably increase direct compaction priority --- mm/page_alloc.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index fa49eb4a5919..e8a0d33cfb67 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3268,6 +3268,14 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, } /* + * Compaction considers all the zones as unfixably fragmented and we + * are on the highest priority, which means it can't be due to + * heuristics and it doesn't really make much sense to retry. + */ + if (compaction_failed(compact_result)) + return false; + + /* * The remaining possibility is that compaction made progress and * created a high-order page, but it was allocated by somebody else. * To prevent thrashing, limit the number of retries in such case. -- 2.8.2