From: Peter Zijlstra Subject: Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc Date: Wed, 25 Aug 2010 14:52:58 +0200 Message-ID: <1282740778.2605.3652.camel@laptop> References: <1282656558.2605.2742.camel@laptop> <4C73CA24.3060707@fusionio.com> <20100825112433.GB4453@thunk.org> <1282736132.2605.3563.camel@laptop> <20100825115709.GD4453@thunk.org> <1282740516.2605.3644.camel@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Cc: David Rientjes , Jens Axboe , Andrew Morton , Neil Brown , Alasdair G Kergon , Chris Mason , Steven Whitehouse , Jan Kara , Frederic Weisbecker , "linux-raid@vger.kernel.org" , "linux-btrfs@vger.kernel.org" , "cluster-devel@redhat.com" , "linux-ext4@vger.kernel.org" , "reiserfs-devel@vger.kernel.org" , "linux-kernel@vger.kernel.org" To: Ted Ts'o Return-path: In-Reply-To: <1282740516.2605.3644.camel@laptop> Sender: linux-btrfs-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org On Wed, 2010-08-25 at 14:48 +0200, Peter Zijlstra wrote: > > > On Wed, 2010-08-25 at 07:24 -0400, Ted Ts'o wrote: > > > > (a) retry the loop in the jbd layer (which Andrew really doesn't > > > > like), (b) keep our own private cache of free memory so we don't fail > > > > and/or loop, > Well (b) sounds a lot saner than either of those. Simply revert to a > state that is sub-optimal but has bounded memory use and reserve that > memory up-front. That way you can always get out of a tight memory spot. Also, there's a good reason for disliking (a), its a deadlock scenario, suppose we need to write out data to get free pages, but the writing out is blocked on requiring free pages. There's really nothing the page allocator can do to help you there, its a situation you have to avoid getting into.