From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/2] xfs: Don't allocate new buffers on every call to _xfs_buf_find
Date: Tue, 9 Aug 2011 03:51:51 -0400 [thread overview]
Message-ID: <20110809075151.GA22968@infradead.org> (raw)
In-Reply-To: <1312786271-10871-2-git-send-email-david@fromorbit.com>
On Mon, Aug 08, 2011 at 04:51:10PM +1000, Dave Chinner wrote:
> -xfs_buf_t *
> +struct xfs_buf *
> xfs_buf_get(
> - xfs_buftarg_t *target,/* target for buffer */
> + struct xfs_buftarg *target,/* target for buffer */
> xfs_off_t ioff, /* starting offset of range */
> size_t isize, /* length of range */
> xfs_buf_flags_t flags)
> {
> - xfs_buf_t *bp, *new_bp;
> + struct xfs_buf *bp;
> + struct xfs_buf *new_bp = NULL;
> int error = 0;
>
> - new_bp = xfs_buf_allocate(flags);
> - if (unlikely(!new_bp))
> - return NULL;
> -
> +again:
> bp = _xfs_buf_find(target, ioff, isize, flags, new_bp);
> - if (bp == new_bp) {
> + if (!(bp || new_bp)) {
> + new_bp = xfs_buf_allocate(flags);
> + if (unlikely(!new_bp))
> + return NULL;
> +
> + _xfs_buf_initialize(new_bp, target, ioff << BBSHIFT,
> + isize << BBSHIFT, flags);
> + goto again;
> + }
> +
> + if (!bp) {
> + xfs_buf_deallocate(new_bp);
> + return NULL;
> + } else if (bp == new_bp) {
> error = xfs_buf_allocate_memory(bp, flags);
> if (error)
> goto no_buffer;
> - } else {
> + } else if (new_bp)
> xfs_buf_deallocate(new_bp);
> - if (unlikely(bp == NULL))
> - return NULL;
> - }
The while loop looks a bit confusing to me. Why not unroll it similar
to how it's done for the VFS inode cache:
bp = _xfs_buf_find(target, ioff, isize, flags, new_bp);
if (bp)
goto found;
new_bp = xfs_buf_allocate(flags);
if (unlikely(!new_bp))
return NULL;
_xfs_buf_initialize(new_bp, target, ioff << BBSHIFT, isize << BBSHIFT,
flags);
bp = _xfs_buf_find(target, ioff, isize, flags, new_bp);
if (!bp) {
xfs_buf_deallocate(new_bp);
return NULL;
}
if (bp == new_bp) {
error = xfs_buf_allocate_memory(bp, flags);
if (error)
goto no_buffer;
}
found:
or even better make sure all buffer initialization is done either as
part of xfs_buf_find or the caller - although we'd need a variant
with caller locking if we want to go down the latter route. This
variant would be nessecary if we ever want to add shared/exclusive or
RCU locking for buffer lookup anyway.
There's also some other weird things here that should be cleaned up
when touching it:
- we should never be able to find a buffer with the wrong mapped
state, so this could be replaced by an assert
- there should be no need to re-assign b_bn and b_count_desired
when we find a buffer
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-08-09 7:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-08 6:51 [PATCH 0/2] xfs: small metadata performance optimisations Dave Chinner
2011-08-08 6:51 ` [PATCH 1/2] xfs: Don't allocate new buffers on every call to _xfs_buf_find Dave Chinner
2011-08-09 7:51 ` Christoph Hellwig [this message]
2011-08-10 5:48 ` Dave Chinner
2011-08-08 6:51 ` [PATCH 2/2] xfs: reduce the number of log forces from tail pushing Dave Chinner
2011-08-14 16:31 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2011-09-30 4:45 [PATCH 0/2] xfs: patches for 3.2 Dave Chinner
2011-09-30 4:45 ` [PATCH 1/2] xfs: Don't allocate new buffers on every call to _xfs_buf_find Dave Chinner
2011-09-30 15:27 ` Christoph Hellwig
2011-10-04 21:30 ` Alex Elder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110809075151.GA22968@infradead.org \
--to=hch@infradead.org \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.