Le 26/06/2014 00:16, Andrew Morton a écrit :
On Tue, 24 Jun 2014 17:52:00 +0200 Sebastien Buisson <sebastien.buisson@xxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
