]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs: optimise CRC updates
authorDave Chinner <dchinner@redhat.com>
Tue, 10 Jan 2017 02:18:50 +0000 (20:18 -0600)
committerEric Sandeen <sandeen@redhat.com>
Tue, 10 Jan 2017 02:18:50 +0000 (20:18 -0600)
commit0bb902147e6abe99e935465770f69814eff427a5
treed6c0cae5da2d47458637337df90429a9cb4d4fc6
parent5d8acc462377b262b5f3ea40caed15d771032e96
xfs: optimise CRC updates

Source kernel commit: cae028df53449905c944603df624ac94bc619661

Nick Piggin reported that the CRC overhead in an fsync heavy
workload was higher than expected on a Power8 machine. Part of this
was to do with the fact that the power8 CRC implementation is not
efficient for CRC lengths of less than 512 bytes, and so the way we
split the CRCs over the CRC field means a lot of the CRCs are
reduced to being less than than optimal size.

To optimise this, change the CRC update mechanism to zero the CRC
field first, and then compute the CRC in one pass over the buffer
and write the result back into the buffer. We can do this safely
because anything writing a CRC has exclusive access to the buffer
the CRC is being calculated over.

We leave the CRC verify code the same - it still splits the CRC
calculation - because we do not want read-only operations modifying
the underlying buffer. This is because read-only operations may not
have an exclusive access to the buffer guaranteed, and so temporary
modifications could leak out to to other processes accessing the
buffer concurrently.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
libxfs/xfs_cksum.h
libxfs/xfs_inode_buf.c