From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751570AbbK1KJE (ORCPT ); Sat, 28 Nov 2015 05:09:04 -0500 Received: from mail-wm0-f49.google.com ([74.125.82.49]:36459 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751274AbbK1KI7 (ORCPT ); Sat, 28 Nov 2015 05:08:59 -0500 Date: Sat, 28 Nov 2015 11:08:56 +0100 From: Michal Hocko To: Vlastimil Babka Cc: linux-mm@kvack.org, Andrew Morton , LKML Subject: Re: [PATCH 1/3] tree wide: get rid of __GFP_REPEAT for order-0 allocations part I Message-ID: <20151128100856.GA7963@dhcp22.suse.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151127093807.GD2493@dhcp22.suse.cz> 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 On Fri 27-11-15 10:38:07, Michal Hocko wrote: [...] > I am not sure whether we found any conclusion here. Are there any strong > arguments against patch 1? I think that should be relatively > non-controversial. What about patch 2? I think it should be ok as well > as we are basically removing the flag which has never had any effect. > > I would like to proceed with this further by going through remaining users. > Most of them depend on a variable size and I am not familiar with the > code so I will talk to maintainer to find out reasoning behind using the > flag. Once we have reasonable number of them I would like to go on and > rename the flag to __GFP_BEST_AFFORD and make it independent on the ble, __GFP_BEST_EFFORT I meant of course... > order. It would still trigger OOM killer where applicable but wouldn't > retry endlessly. > > Does this sound like a reasonable plan? -- Michal Hocko SUSE Labs