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@xxxxxxxxxx> > > > > 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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
