From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933417AbbKMKSj (ORCPT ); Fri, 13 Nov 2015 05:18:39 -0500 Received: from mx2.suse.de ([195.135.220.15]:53896 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932299AbbKMKSf (ORCPT ); Fri, 13 Nov 2015 05:18:35 -0500 Date: Fri, 13 Nov 2015 10:18:31 +0000 From: Mel Gorman To: mhocko@kernel.org Cc: Andrew Morton , linux-mm@kvack.org, LKML , Michal Hocko Subject: Re: [PATCH] mm: get rid of __alloc_pages_high_priority Message-ID: <20151113101831.GF19677@suse.de> References: <1447343618-19696-1-git-send-email-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1447343618-19696-1-git-send-email-mhocko@kernel.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 12, 2015 at 04:53:38PM +0100, mhocko@kernel.org wrote: > From: Michal Hocko > > __alloc_pages_high_priority doesn't do anything special other than it > calls get_page_from_freelist and loops around GFP_NOFAIL allocation > until it succeeds. It would be better if the first part was done in > __alloc_pages_slowpath where we modify the zonelist because this would > be easier to read and understand. And do the retry at the very same > place because retrying without even attempting to do any reclaim is > fragile because we are basically relying on somebody else to make the > reclaim (be it the direct reclaim or OOM killer) for us. The caller > might be holding resources (e.g. locks) which block other other > reclaimers from making any progress for example. > > Remove the helper and open code it into its only user. We have to be > careful about __GFP_NOFAIL allocations from the PF_MEMALLOC context > even though this is a very bad idea to begin with because no progress > can be gurateed at all. We shouldn't break the __GFP_NOFAIL semantic > here though. It could be argued that this is essentially GFP_NOWAIT > context which we do not support but PF_MEMALLOC is much harder to check > for existing users because they might happen deep down the code path > performed much later after setting the flag so we cannot really rule out > there is no kernel path triggering this combination. > > Signed-off-by: Michal Hocko Acked-by: Mel Gorman -- Mel Gorman SUSE Labs