summaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_buf.h
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2016-12-05 14:40:32 +1100
committerDave Chinner <david@fromorbit.com>2016-12-05 14:40:32 +1100
commitcae028df53449905c944603df624ac94bc619661 (patch)
tree3a9e712f2a2ff109f77c0854956ea9370e8deca3 /fs/xfs/xfs_buf.h
parent11ef38afe98cc7ad1a46ef24945232ec1760d5e2 (diff)
downloadlinux-stable-cae028df53449905c944603df624ac94bc619661.tar.gz
linux-stable-cae028df53449905c944603df624ac94bc619661.tar.bz2
linux-stable-cae028df53449905c944603df624ac94bc619661.zip
xfs: optimise CRC updates
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>
Diffstat (limited to 'fs/xfs/xfs_buf.h')
0 files changed, 0 insertions, 0 deletions