public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox