From: Peter Zijlstra Subject: Re: [patch 1/5] mm: add nofail variants of kmalloc kcalloc and kzalloc Date: Wed, 25 Aug 2010 16:13:20 +0200 Message-ID: <1282745600.2605.3751.camel@laptop> References: <1282656558.2605.2742.camel@laptop> <4C73CA24.3060707@fusionio.com> <20100825112433.GB4453@thunk.org> 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: Received: from casper.infradead.org ([85.118.1.10]:44471 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753047Ab0HYONt convert rfc822-to-8bit (ORCPT ); Wed, 25 Aug 2010 10:13:49 -0400 In-Reply-To: <20100825112433.GB4453@thunk.org> Sender: linux-ext4-owner@vger.kernel.org List-ID: On Wed, 2010-08-25 at 07:24 -0400, Ted Ts'o wrote: > There are other places where we can fail safely (for example, in jbd's > start_this_handle, although that just pushes the layer up the stack, > and ultimately, to userspace where most userspace programs don't > really expect ENOMEM to get returned by a random disk write While talking with Chris about this, if you can indeed push the error out that far you can basically ensure this particular fs-op does not complicate the journal commit and thereby limit the number of extra entries in your journal, and thus the amount of memory required. So once stuff starts failing, push out ops back out of the filesystem code, force a journal commit, and then let these ops retry. There is no need to actually push the -ENOMEM all the way back to userspace.