From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastien Buisson Subject: Re: [PATCH] Allow increasing the buffer-head per-CPU LRU size Date: Thu, 26 Jun 2014 13:44:12 +0200 Message-ID: <53AC078C.4090005@bull.net> References: <53A99EA0.3010800@bull.net> <20140625151638.00b7c2aa29f79f63dce7ae56@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: , , , , To: Andrew Morton Return-path: In-Reply-To: <20140625151638.00b7c2aa29f79f63dce7ae56@linux-foundation.org> Sender: linux-doc-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Le 26/06/2014 00:16, Andrew Morton a =E9crit : > On Tue, 24 Jun 2014 17:52:00 +0200 Sebastien Buisson wrote: > >> Allow increasing the buffer-head per-CPU LRU size to allow efficient >> filesystem operations that access many blocks for each transaction. >> For example, creating a file in a large ext4 directory with quota >> enabled will accesses multiple buffer heads and will overflow the LR= U >> at the default 8-block LRU size: >> >> * parent directory inode table block (ctime, nlinks for subdirs) >> * new inode bitmap >> * inode table block >> * 2 quota blocks >> * directory leaf block (not reused, but pollutes one cache entry) >> * 2 levels htree blocks (only one is reused, other pollutes cache) >> * 2 levels indirect/index blocks (only one is reused) >> >> Make this tuning be a kernel parameter 'bh_lru_size'. > > I don't think it's a great idea to make this a boot-time tunable. It= 's > going to take a ton of work by each and every kernel > user/installer/distributor to work out what is the best setting for > them. And the differences will be pretty small anyway. And we didn'= t > provide them with any documentation to help them even get started wit= h > the project. > I am sorry, I meant to leave the default bh_lru_size as is, ie set to 8= =20 (instead of 16 in my proposed patch). That way, kernel users and=20 integrators of all kind would not have to bother about the new boot-tim= e=20 tunable, and could change nothing and stay with the same value as they=20 did before. At the same time, advanced users like those playing with Lustre would=20 have the ability to tune the buffer-head per-CPU LRU size without the=20 need to recompile the kernel. Does it sound better?