summaryrefslogtreecommitdiff
path: root/fs/xfs
diff options
context:
space:
mode:
authorDarrick J. Wong <darrick.wong@oracle.com>2019-07-05 10:29:56 -0700
committerDarrick J. Wong <darrick.wong@oracle.com>2019-07-05 10:29:56 -0700
commit036f463fe15db26c2d90724203e4a7ea8f9b8580 (patch)
tree80961f1c6ddd147992c4d1213577e416d0a5e26b /fs/xfs
parent6d6ccedd76823c28115bd6925342ceb73bab6cd4 (diff)
downloadlinux-rpi-036f463fe15db26c2d90724203e4a7ea8f9b8580.tar.gz
linux-rpi-036f463fe15db26c2d90724203e4a7ea8f9b8580.tar.bz2
linux-rpi-036f463fe15db26c2d90724203e4a7ea8f9b8580.zip
xfs: online scrub needn't bother zeroing its temporary buffer
The xattr scrubber functions use the temporary memory buffer either for storing bitmaps or for testing if attribute value extraction works. The bitmap code always zeroes what it needs and the value extraction sets the buffer contents, so it's not necessary to waste CPU time zeroing on allocation. Note that while we never read the contents that the attr value extraction function sets, we do need to call it to check the remote attribute header and CRCs to check for corruption. A flame graph analysis showed that we were spending 7% of a xfs_scrub run (the whole program, not just the attr scrubber itself) allocating and zeroing 64k segments needlessly. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Brian Foster <bfoster@redhat.com>
Diffstat (limited to 'fs/xfs')
-rw-r--r--fs/xfs/scrub/attr.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/fs/xfs/scrub/attr.c b/fs/xfs/scrub/attr.c
index 266fecbbf98a..1afc58bf71dd 100644
--- a/fs/xfs/scrub/attr.c
+++ b/fs/xfs/scrub/attr.c
@@ -53,7 +53,11 @@ xchk_setup_xattr_buf(
sc->buf = NULL;
}
- ab = kmem_zalloc_large(sizeof(*ab) + sz, flags);
+ /*
+ * Don't zero the buffer upon allocation to avoid runtime overhead.
+ * All users must be careful never to read uninitialized contents.
+ */
+ ab = kmem_alloc_large(sizeof(*ab) + sz, flags);
if (!ab)
return -ENOMEM;