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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53AC078C.4090005@bull.net>
Date:	Thu, 26 Jun 2014 13:44:12 +0200
From:	Sebastien Buisson <sebastien.buisson@...l.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	<rob@...dley.net>, <viro@...iv.linux.org.uk>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] Allow increasing the buffer-head per-CPU LRU size


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