Re: [PATCH] Allow increasing the buffer-head per-CPU LRU size

[Sebastien Buisson <sebastien.buisson@bull.net>]

Le 26/06/2014 00:16, Andrew Morton a écrit :
> On Tue, 24 Jun 2014 17:52:00 +0200 Sebastien Buisson <sebastien.buisson@bull.net> 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 LRU
>> 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 with
> the project.
>

I am sorry, I meant to leave the default bh_lru_size as is, ie set to 8 
(instead of 16 in my proposed patch). That way, kernel users and 
integrators of all kind would not have to bother about the new boot-time 
tunable, and could change nothing and stay with the same value as they 
did before.

At the same time, advanced users like those playing with Lustre would 
have the ability to tune the buffer-head per-CPU LRU size without the 
need to recompile the kernel.

Does it sound better?