diff options
author | Eric Biggers <ebiggers@google.com> | 2020-01-06 12:54:10 -0800 |
---|---|---|
committer | Eric Biggers <ebiggers@google.com> | 2020-01-14 13:27:32 -0800 |
commit | c22415d333fbab0475762e98e1bbffb9b17a8b68 (patch) | |
tree | 6c62320e2cc72cf66721483ecdf6ccbdf9282d26 /Makefile | |
parent | fd6988496e79a6a4bdb514a4655d2920209eb85d (diff) | |
download | lwn-c22415d333fbab0475762e98e1bbffb9b17a8b68.tar.gz lwn-c22415d333fbab0475762e98e1bbffb9b17a8b68.zip |
fs-verity: implement readahead for FS_IOC_ENABLE_VERITY
When it builds the first level of the Merkle tree, FS_IOC_ENABLE_VERITY
sequentially reads each page of the file using read_mapping_page().
This works fine if the file's data is already in pagecache, which should
normally be the case, since this ioctl is normally used immediately
after writing out the file.
But in any other case this implementation performs very poorly, since
only one page is read at a time.
Fix this by implementing readahead using the functions from
mm/readahead.c.
This improves performance in the uncached case by about 20x, as seen in
the following benchmarks done on a 250MB file (on x86_64 with SHA-NI):
FS_IOC_ENABLE_VERITY uncached (before) 3.299s
FS_IOC_ENABLE_VERITY uncached (after) 0.160s
FS_IOC_ENABLE_VERITY cached 0.147s
sha256sum uncached 0.191s
sha256sum cached 0.145s
Note: we could instead switch to kernel_read(). But that would mean
we'd no longer be hashing the data directly from the pagecache, which is
a nice optimization of its own. And using kernel_read() would require
allocating another temporary buffer, hashing the data and tree pages
separately, and explicitly zero-padding the last page -- so it wouldn't
really be any simpler than direct pagecache access, at least for now.
Link: https://lore.kernel.org/r/20200106205410.136707-1-ebiggers@kernel.org
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions