Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932516AbcDKP4T (ORCPT ); Mon, 11 Apr 2016 11:56:19 -0400 Received: from mail-qg0-f68.google.com ([209.85.192.68]:33029 "EHLO mail-qg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932307AbcDKP4O (ORCPT ); Mon, 11 Apr 2016 11:56:14 -0400 Date: Mon, 11 Apr 2016 17:40:37 +0200 From: Michal Hocko To: Andrew Morton Cc: Linus Torvalds , Johannes Weiner , Mel Gorman , David Rientjes , Tetsuo Handa , Joonsoo Kim , Hillf Danton , linux-mm@kvack.org, LKML Subject: Re: [PATCH 09/11] mm, compaction: Abstract compaction feedback to helpers Message-ID: <20160411154036.GN23157@dhcp22.suse.cz> References: <1459855533-4600-1-git-send-email-mhocko@kernel.org> <1459855533-4600-10-git-send-email-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1459855533-4600-10-git-send-email-mhocko@kernel.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2075 Lines: 65 Hi Andrew, Vlastimil has pointed out[1] that using compaction_withdrawn() for THP allocations has some non-trivial consequences. While I still think that the check is OK it is true we shouldn't sneak in a potential behavior change into something that basically provides an API. So can you fold the following partial revert into the original patch please? [1] http://lkml.kernel.org/r/570BB719.2030007@suse.cz --- >From 71ddeee4238e33d67ef07883e73f946a7cc40e73 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Mon, 11 Apr 2016 17:38:22 +0200 Subject: [PATCH] ction-abstract-compaction-feedback-to-helpers-fix Preserve the original thp back off checks to not introduce any functional changes as per Vlastimil. Signed-off-by: Michal Hocko --- mm/page_alloc.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index c05de84c8157..c37e6d1ad643 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3362,12 +3362,25 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, if (page) goto got_pg; - /* - * Checks for THP-specific high-order allocations and back off - * if the the compaction backed off - */ - if (is_thp_gfp_mask(gfp_mask) && compaction_withdrawn(compact_result)) - goto nopage; + /* Checks for THP-specific high-order allocations */ + if (is_thp_gfp_mask(gfp_mask)) { + /* + * If compaction is deferred for high-order allocations, it is + * because sync compaction recently failed. If this is the case + * and the caller requested a THP allocation, we do not want + * to heavily disrupt the system, so we fail the allocation + * instead of entering direct reclaim. + */ + if (compact_result == COMPACT_DEFERRED) + goto nopage; + + /* + * Compaction is contended so rather back off than cause + * excessive stalls. + */ + if(compact_result == COMPACT_CONTENDED) + goto nopage; + } /* * It can become very expensive to allocate transparent hugepages at -- 2.8.0.rc3 -- Michal Hocko SUSE Labs