From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752436AbcGSXKm (ORCPT ); Tue, 19 Jul 2016 19:10:42 -0400 Received: from mail-pa0-f52.google.com ([209.85.220.52]:33336 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752032AbcGSXKj (ORCPT ); Tue, 19 Jul 2016 19:10:39 -0400 Date: Tue, 19 Jul 2016 16:10:31 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Vlastimil Babka cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michal Hocko , Mel Gorman , Joonsoo Kim , Rik van Riel Subject: Re: [PATCH 5/8] mm, page_alloc: make THP-specific decisions more generic In-Reply-To: <20160718112302.27381-6-vbabka@suse.cz> Message-ID: References: <20160718112302.27381-1-vbabka@suse.cz> <20160718112302.27381-6-vbabka@suse.cz> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 Jul 2016, Vlastimil Babka wrote: > Since THP allocations during page faults can be costly, extra decisions are > employed for them to avoid excessive reclaim and compaction, if the initial > compaction doesn't look promising. The detection has never been perfect as > there is no gfp flag specific to THP allocations. At this moment it checks the > whole combination of flags that makes up GFP_TRANSHUGE, and hopes that no other > users of such combination exist, or would mind being treated the same way. > Extra care is also taken to separate allocations from khugepaged, where latency > doesn't matter that much. > > It is however possible to distinguish these allocations in a simpler and more > reliable way. The key observation is that after the initial compaction followed > by the first iteration of "standard" reclaim/compaction, both __GFP_NORETRY > allocations and costly allocations without __GFP_REPEAT are declared as > failures: > > /* Do not loop if specifically requested */ > if (gfp_mask & __GFP_NORETRY) > goto nopage; > > /* > * Do not retry costly high order allocations unless they are > * __GFP_REPEAT > */ > if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT)) > goto nopage; > > This means we can further distinguish allocations that are costly order *and* > additionally include the __GFP_NORETRY flag. As it happens, GFP_TRANSHUGE > allocations do already fall into this category. This will also allow other > costly allocations with similar high-order benefit vs latency considerations to > use this semantic. Furthermore, we can distinguish THP allocations that should > try a bit harder (such as from khugepageed) by removing __GFP_NORETRY, as will > be done in the next patch. > > Signed-off-by: Vlastimil Babka > Acked-by: Michal Hocko I think this is fine, but I would hope that we could check gfp_pfmemalloc_allowed() before compacting and failing even for costly orders when otherwise the first get_page_from_freelist() in the slowpath may have succeeded due to watermarks.