[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200114213130.GG41220@gmail.com>
Date: Tue, 14 Jan 2020 13:31:31 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: linux-fscrypt@...r.kernel.org
Cc: linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
Victor Hsieh <victorhsieh@...gle.com>,
linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH v2] fs-verity: implement readahead of Merkle
tree pages
On Mon, Jan 06, 2020 at 12:55:33PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@...gle.com>
>
> When fs-verity verifies data pages, currently it reads each Merkle tree
> page synchronously using read_mapping_page().
>
> Therefore, when the Merkle tree pages aren't already cached, fs-verity
> causes an extra 4 KiB I/O request for every 512 KiB of data (assuming
> that the Merkle tree uses SHA-256 and 4 KiB blocks). This results in
> more I/O requests and performance loss than is strictly necessary.
>
> Therefore, implement readahead of the Merkle tree pages.
>
> For simplicity, we take advantage of the fact that the kernel already
> does readahead of the file's *data*, just like it does for any other
> file. Due to this, we don't really need a separate readahead state
> (struct file_ra_state) just for the Merkle tree, but rather we just need
> to piggy-back on the existing data readahead requests.
>
> We also only really need to bother with the first level of the Merkle
> tree, since the usual fan-out factor is 128, so normally over 99% of
> Merkle tree I/O requests are for the first level.
>
> Therefore, make fsverity_verify_bio() enable readahead of the first
> Merkle tree level, for up to 1/4 the number of pages in the bio, when it
> sees that the REQ_RAHEAD flag is set on the bio. The readahead size is
> then passed down to ->read_merkle_tree_page() for the filesystem to
> (optionally) implement if it sees that the requested page is uncached.
>
> While we're at it, also make build_merkle_tree_level() set the Merkle
> tree readahead size, since it's easy to do there.
>
> However, for now don't set the readahead size in fsverity_verify_page(),
> since currently it's only used to verify holes on ext4 and f2fs, and it
> would need parameters added to know how much to read ahead.
>
> This patch significantly improves fs-verity sequential read performance.
> Some quick benchmarks with 'cat'-ing a 250MB file after dropping caches:
>
> On an ARM64 phone (using sha256-ce):
> Before: 217 MB/s
> After: 263 MB/s
> (compare to sha256sum of non-verity file: 357 MB/s)
>
> In an x86_64 VM (using sha256-avx2):
> Before: 173 MB/s
> After: 215 MB/s
> (compare to sha256sum of non-verity file: 223 MB/s)
>
> Signed-off-by: Eric Biggers <ebiggers@...gle.com>
> ---
>
> Changed v1 => v2:
> - Ensure that the pages continue being marked accessed when they're
> already cached and Uptodate.
> - Removed unnecessary IS_ERR(page) checks.
> - Adjusted formatting of the prototype of f2fs_mpage_readpages() to
> avoid a merge conflict with the f2fs tree.
>
> fs/ext4/verity.c | 47 ++++++++++++++++++++++++++++++++++--
> fs/f2fs/data.c | 2 +-
> fs/f2fs/f2fs.h | 3 +++
> fs/f2fs/verity.c | 47 ++++++++++++++++++++++++++++++++++--
> fs/verity/enable.c | 8 +++++-
> fs/verity/fsverity_private.h | 1 +
> fs/verity/open.c | 1 +
> fs/verity/verify.c | 34 +++++++++++++++++++++-----
> include/linux/fsverity.h | 7 +++++-
> 9 files changed, 137 insertions(+), 13 deletions(-)
Applied to fscrypt.git#fsverity for 5.6.
- Eric
Powered by blists - more mailing lists