Re: [PATCH] [RFC v2] xfs: byte range buffer dirty region tracking

[Dave Chinner <david@fromorbit.com>]

On Wed, Jun 03, 2015 at 10:01:21AM -0400, Brian Foster wrote:
> On Fri, May 29, 2015 at 12:16:17PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > The biggest problem with large directory block sizes is the CPU
> > overhead in maintaining the buffer log item direty region bitmap.
> > The bit manipulations and buffer region mapping calls are right at
> > the top of the profiles when running tests on 64k directory buffers:
.....
> > +	start = 0;
> > +	if (offset < rp->first)
> > +		start = rp->first - offset;
> > +	end = length - 1;
> > +	if (offset + length > rp->last)
> > +		end = rp->last - offset - 1;
> > +
> > +	start &= ~((1 << XFS_BLF_SHIFT) - 1);
> > +	first_bit = start >> XFS_BLF_SHIFT;
> > +	last_bit = end >> XFS_BLF_SHIFT;
> > +	nbits = last_bit - first_bit + 1;
> > +	bitmap_set((unsigned long *)blfp->blf_data_map, first_bit, nbits);
> > +
> > +	ASSERT(end <= length);
> > +	ASSERT(start <= length);
> > +	ASSERT(length >= nbits * XFS_BLF_CHUNK);
> > +	/*
> > +	 * Copy needs to be done a buffer page at a time as we can be logging
> > +	 * unmapped buffers. hence we have to use xfs_buf_iomove() rather than a
> > +	 * straight memcpy here.
> > +	 */
> > +	offset += first_bit * XFS_BLF_CHUNK;
> > +	length = nbits * XFS_BLF_CHUNK;
> > +	buf = xlog_prepare_iovec(lv, vecp, XLOG_REG_TYPE_BCHUNK);
> > +	xfs_buf_iomove(bp, offset, length, buf, XBRW_READ);
> > +	xlog_finish_iovec(lv, *vecp, length);
> 
> Am I following this correctly in that the bitmap lives on because it's
> part of the on-disk log structure?

Yes.

> In other words, we previously updated
> the per-segment bitmaps during the action of logging the buffer and this
> would simply copy the format to the log vector. With this change, we
> have the separate item-wide logging range that is effectively an in-core
> value and used to track the log action. The segment bitmaps must still
> be written to the log to preserve on-disk format, so we defer that to
> when the log buffer is formatted and do so against the copy of the
> format that's actually already copied to the log vector (e.g., via the
> blfp = xlog_copy_iovec(...) above).

Yes.

> Just a minor nit if I am following that correctly... it would be nice if
> the comment above were a bit more explicit to point out we're working on
> the copied format since the bitmap updates are deferred (and the bitmaps
> in the source memory buffer are essentially never valid).

Yep, I can add that.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs