From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753172AbbFHOyn (ORCPT ); Mon, 8 Jun 2015 10:54:43 -0400 Received: from imap.thunk.org ([74.207.234.97]:52980 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751967AbbFHOyg (ORCPT ); Mon, 8 Jun 2015 10:54:36 -0400 Date: Mon, 8 Jun 2015 10:54:32 -0400 From: "Theodore Ts'o" To: Michal Hocko Cc: linux-ext4@vger.kernel.org, David Rientjes , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, LKML Subject: Re: [PATCH -resend] jbd2: revert must-not-fail allocation loops back to GFP_NOFAIL Message-ID: <20150608145432.GB19168@thunk.org> Mail-Followup-To: Theodore Ts'o , Michal Hocko , linux-ext4@vger.kernel.org, David Rientjes , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, LKML References: <1433770124-19614-1-git-send-email-mhocko@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1433770124-19614-1-git-send-email-mhocko@suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 08, 2015 at 03:28:44PM +0200, Michal Hocko wrote: > This basically reverts 47def82672b3 (jbd2: Remove __GFP_NOFAIL from jbd2 > layer). The deprecation of __GFP_NOFAIL was a bad choice because it led > to open coding the endless loop around the allocator rather than > removing the dependency on the non failing allocation. So the > deprecation was a clear failure and the reality tells us that > __GFP_NOFAIL is not even close to go away. > > It is still true that __GFP_NOFAIL allocations are generally discouraged > and new uses should be evaluated and an alternative (pre-allocations or > reservations) should be considered but it doesn't make any sense to lie > the allocator about the requirements. Allocator can take steps to help > making a progress if it knows the requirements. > > Signed-off-by: Michal Hocko > Acked-by: David Rientjes Applied, thanks. - Ted