[PATCH 0/3] xfs: buffer log item optimisations

[Dave Chinner <david@fromorbit.com>]

Hi folks,

A couple of optimisations and a bug fix that I don't think we could
trigger.

The bug fix was that we weren't passing the segment offset into the
buffer log item sizing calculation, so we weren't calculating when
we spanned discontiguous pages in the buffers correctly. I don't
think this ever mattered, because all buffers larger than a single
page are vmapped (so a contiguous virtual address range) and the
only direct mapped buffers we have are inode cluster buffers and
they never span discontiguous extents. Hence while the code is
clearly wrong, we never actually trigger the situation where it
results in an incorrect calculation. However, changing the way we
calculate the size of the dirty regions is difficult if we don't do
this calc the same way as the formatting code, so fix it.

The first optimisation is simply a mechanism to reduce the amount of
allocation and freeing overhead on the buffer item shadow buffer as
we increase the amount of the buffer that is dirty as we relog it.

The last optimisation is (finally) addressing the overhead of bitmap
based dirty tracking of the buffer log item. We walk a bit at a
time, calling xfs_buf_offset() at least twice for each bit in both
the size and the formatting code to see if the region crosses a
discontiguity in the buffer address space. This is expensive. The
log recovery code uses contiguous bit range detection to do the
same thing, so I've updated the logging code to operate on
contiguous bit ranges and only fall back to bit-by-bit checking in
the rare case that a contiguous dirty range spans an address space
discontiguity and hence has to be split into multiple regions to
copy it into the log.

This enables big performance improvements when using large directory
block sizes.

Cheers,

Dave.