From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751781AbcGUHA4 (ORCPT ); Thu, 21 Jul 2016 03:00:56 -0400 Received: from mx2.suse.de ([195.135.220.15]:38900 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751166AbcGUHAu (ORCPT ); Thu, 21 Jul 2016 03:00:50 -0400 Subject: Re: [PATCH 2/8] mm, page_alloc: set alloc_flags only once in slowpath To: David Rientjes References: <20160718112302.27381-1-vbabka@suse.cz> <20160718112302.27381-3-vbabka@suse.cz> Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michal Hocko , Mel Gorman , Joonsoo Kim , Rik van Riel From: Vlastimil Babka Message-ID: <49843a12-3b00-06f5-8645-098e875ec075@suse.cz> Date: Thu, 21 Jul 2016 09:00:46 +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: 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 07/20/2016 12:28 AM, David Rientjes wrote: > On Mon, 18 Jul 2016, Vlastimil Babka wrote: > >> In __alloc_pages_slowpath(), alloc_flags doesn't change after it's initialized, >> so move the initialization above the retry: label. Also make the comment above >> the initialization more descriptive. >> >> The only exception in the alloc_flags being constant is ALLOC_NO_WATERMARKS, >> which may change due to TIF_MEMDIE being set on the allocating thread. We can >> fix this, and make the code simpler and a bit more effective at the same time, >> by moving the part that determines ALLOC_NO_WATERMARKS from >> gfp_to_alloc_flags() to gfp_pfmemalloc_allowed(). This means we don't have to >> mask out ALLOC_NO_WATERMARKS in numerous places in __alloc_pages_slowpath() >> anymore. The only two tests for the flag can instead call >> gfp_pfmemalloc_allowed(). >> >> Signed-off-by: Vlastimil Babka > > Acked-by: David Rientjes > > Looks good, although maybe a new name for gfp_pfmemalloc_allowed() would > be in order. I don't disagree... any good suggestions? :)