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: <20140625151638.00b7c2aa29f79f63dce7ae56@linux-foundation.org>
Date:	Wed, 25 Jun 2014 15:16:38 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Sebastien Buisson <sebastien.buisson@...l.net>
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

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.

Other approaches: 

- Perform some boot-time auto-sizing, perhaps based on memory size,
  cpu counts, etc.

  None of which will be very successful, because the LRU miss rate is
  dependent on filesystem type and usage, not on system size.

- Perform some runtime resizing: if the miss rate gets "too high"
  then increase the LRU size.  Maybe decrease it as well, or maybe not.

  This will get more complex and we'd require decent improvements to
  justify the change.

- Just increase BH_LRU_SIZE to 16!

I think the third option should be the first choice.  It doesn't get
simpler than that and any more complex option would need additional
testing-based justification on top of this simplest approach.

I'm amused that my dopey-but-simple LRU management code has survived
these 12-odd years.  I suspect that if the LRUs get much larger, we'll
be needing something less dopey and simple in there.

It's good to see (indirect) evidence that the LRUs are actually doing
something useful.
--
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/