public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/2] xfs: Don't allocate new buffers on every call to _xfs_buf_find
Date: Wed, 10 Aug 2011 15:48:27 +1000	[thread overview]
Message-ID: <20110810054827.GZ3162@dastard> (raw)
In-Reply-To: <20110809075151.GA22968@infradead.org>

On Tue, Aug 09, 2011 at 03:51:51AM -0400, Christoph Hellwig wrote:
> 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:

Makes sense.

> 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.

I'll leave that problem for when RCU-izing the lookup - I haven't
quite worked out what the best way of doing that is yet, 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

OK.

>  - there should be no need to re-assign b_bn and b_count_desired
>    when we find a buffer

Yes, definitely.

I'm also tempted to rename some variables to make it more obvious
what units they are in and to reduce the conversions we do from
one type to another.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2011-08-10  5:48 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
2011-08-10  5:48     ` Dave Chinner [this message]
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=20110810054827.GZ3162@dastard \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --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