From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: Is nobh code still useful? Date: Sun, 20 Sep 2009 20:17:20 +0200 Message-ID: <20090920181720.GC16919@duck.suse.cz> References: <20090917135627.GB13660@duck.suse.cz> <4AB30AD1.7010400@us.ibm.com> <20090918141226.GB26991@mit.edu> <20090918162554.13a72664@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Theodore Tso , Badari Pulavarty , Jan Kara , linux-fsdevel@vger.kernel.org, LKML , Andrew Morton To: Arjan van de Ven Return-path: Received: from cantor.suse.de ([195.135.220.2]:56199 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753616AbZITSRW (ORCPT ); Sun, 20 Sep 2009 14:17:22 -0400 Content-Disposition: inline In-Reply-To: <20090918162554.13a72664@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri 18-09-09 16:25:54, Arjan van de Ven wrote: > On Fri, 18 Sep 2009 10:12:26 -0400 > Theodore Tso wrote: > > On Thu, Sep 17, 2009 at 09:21:37PM -0700, Badari Pulavarty wrote: > > > > > > Originally it was supported on ext2. I added support nobh support > > > for ext3. At that time, the main > > > issue/complaint was that, these bufferheads consume memory from > > > ZONE_NORMAL causing > > > memory pressure on 32-bit (i386) configurations. > > > > Specifically, it matters on very large configuration systems (i.e., > > 32GB-64GB using PAE-36) that today we'd probably just say, "use > > x86_64, you moron". It would probably matter if someone were to want > > to upgrade a non-64-bit capable machine to a newer kernel. > > > > Dropping nobh from ext3 at this point might prevent some of these > > older systems from upgrading, I'm not sure how much we would care; on > > the one hand, these machines tended to be pretty expensive, so people > > would probably want to use them for a while. On the other hand, it > > has been over five years now since x86_64 machines have been > > available, and many of these customers are highly unlikely to want to > > upgrade anyway. > > isn't the converse to just make nobh the default but not an option a > better approach then? > I forgot why this was a good idea to be an option again ;-) Buffer heads cache useful information so without them, IO may become more more CPU intensive (allocating and freeing temporary buffer heads, setting up block mapping etc.). Also some features like delayed allocation need buffer head bits - that is why e.g. ext4 doesn't really support nobh mount option. Honza -- Jan Kara SUSE Labs, CR