From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751451AbbLUMSX (ORCPT ); Mon, 21 Dec 2015 07:18:23 -0500 Received: from mx2.suse.de ([195.135.220.15]:57884 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751145AbbLUMSW (ORCPT ); Mon, 21 Dec 2015 07:18:22 -0500 Subject: Re: [PATCH 1/3] tree wide: get rid of __GFP_REPEAT for order-0 allocations part I To: Michal Hocko References: <1446740160-29094-1-git-send-email-mhocko@kernel.org> <1446740160-29094-2-git-send-email-mhocko@kernel.org> <5641185F.9020104@suse.cz> <20151110125101.GA8440@dhcp22.suse.cz> <564C8801.2090202@suse.cz> <20151127093807.GD2493@dhcp22.suse.cz> <565C8129.80302@suse.cz> <20151201162718.GA4662@dhcp22.suse.cz> Cc: linux-mm@kvack.org, Andrew Morton , LKML From: Vlastimil Babka Message-ID: <5677EE0B.7090606@suse.cz> Date: Mon, 21 Dec 2015 13:18:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151201162718.GA4662@dhcp22.suse.cz> 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 12/01/2015 05:27 PM, Michal Hocko wrote: > On Mon 30-11-15 18:02:33, Vlastimil Babka wrote: > [...] >> So the issue I see with simply renaming __GFP_REPEAT to __GFP_BEST_AFFORD >> and making it possible to fail for low orders, is that it will conflate the >> new failure possibility with the existing "try harder to reclaim before >> oom". As I mentioned before, "trying harder" could be also extended to mean >> something for compaction, but that would further muddle the meaning of the >> flag. Maybe the cleanest solution would be to have separate flags for >> "possible to fail" (let's say __GFP_MAYFAIL for now) and "try harder" (e.g. >> __GFP_TRY_HARDER)? And introduce two new higher-level "flags" of a GFP_* >> kind, that callers would use instead of GFP_KERNEL, where one would mean >> GFP_KERNEL|__GFP_MAYFAIL and the other >> GFP_KERNEL|__GFP_TRY_HARDER|__GFP_MAYFAIL. > > I will think about that but this sounds quite confusing to me. All the > allocations on behalf of a user process are MAYFAIL basically (e.g. the > oom victim failure case) unless they are explicitly __GFP_NOFAIL. It > also sounds that ~__GFP_NOFAIL should imply MAYFAIL automatically. > __GFP_BEST_EFFORT on the other hand clearly states that the allocator > should try its best but it can fail. The way how it achieves that is > an implementation detail and users do not have to care. In your above > hierarchy of QoS we have: > - no reclaim ~__GFP_DIRECT_RECLAIM - optimistic allocation with a > fallback (e.g. smaller allocation request) > - no destructive reclaim __GFP_NORETRY - allocation with a more > expensive fallback (e.g. vmalloc) Maybe it would be less confusing / more consistent if __GFP_NORETRY was renamed to __GFP_LOW_EFFORT ? > - all reclaim types but only fail if there is no good hope for success > __GFP_BEST_EFFORT (fail rather than invoke the OOM killer second time) > user allocations > - no failure allowed __GFP_NOFAIL - failure mode is not acceptable > > we can keep the current implicit "low order imply __GFP_NOFAIL" behavior > of the GFP_KERNEL and still offer users to use __GFP_BEST_EFFORT as a > way to override it. > >> The second thing to consider, is __GFP_NORETRY useful? The latency savings >> are quite vague. Maybe we could just remove this flag to make space for >> __GFP_MAYFAIL? > > There are users who would like to see some reclaim but rather fail then > see the OOM killer. I assume there are also users who can handle the > failure but the OOM killer is not a big deal for them. I think that > GFP_USER is an example of the later. >