public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Elder <aelder@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 4/6] xfs: optimize xfs_alloc_fix_freelist
Date: Fri, 28 Jan 2011 16:17:48 -0600	[thread overview]
Message-ID: <1296253068.2342.282.camel@doink> (raw)
In-Reply-To: <20110121092551.185804716@bombadil.infradead.org>

On Fri, 2011-01-21 at 04:22 -0500, Christoph Hellwig wrote:
> plain text document attachment
> (xfs-avoid-sync-transaction-for-freelist-refill)
> If we shorten the freelist in xfs_alloc_fix_freelist there is no need
> to wait for busy blocks as they will be marked busy again when we call
> xfs_free_ag_extent.  Avoid this by not marking blocks coming from the
> freelist as busy in xfs_free_ag_extent, and not marking transactions
> with busy extents as synchronous in xfs_alloc_get_freelist.  Unlike
> xfs_free_ag_extent which already has the isfl argument,
> xfs_alloc_get_freelist needs to be told about the usage of the blocks
> it returns.  For this we extend the btreeblk flag to a type argument
> which specifies in detail what the block is going to be used for.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Now that I've found my way through the paths that this
code touches (Dave's analysis helped a lot), I understand
what you're doing and I think it looks good.

I agree that the XFS_FREELIST_* symbols need a little
explanation.

And on a broader subject, it might be nice if the sort
of lifecycle of this kind of thing was documented
somewhere (maybe it is).  It would be really cool if
certain changes could point to a Wiki page with a
diagram of what's going on or something.  Nah...

Reviewed-by: Alex Elder <aelder@sgi.com>


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

  parent reply	other threads:[~2011-01-28 22:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-21  9:22 [PATCH 0/6] do not reuse busy extents Christoph Hellwig
2011-01-21  9:22 ` [PATCH 1/6] xfs: clean up the xfs_alloc_compute_aligned calling convention Christoph Hellwig
2011-01-25  4:23   ` Dave Chinner
2011-01-27 23:21   ` Alex Elder
2011-01-21  9:22 ` [PATCH 3/6] xfs: do not immediately reuse busy extent ranges Christoph Hellwig
2011-01-27 23:20   ` Alex Elder
2011-01-28  1:58   ` Dave Chinner
2011-01-28 16:19     ` Alex Elder
2011-01-29  0:25       ` Dave Chinner
2011-01-21  9:22 ` [PATCH 4/6] xfs: optimize xfs_alloc_fix_freelist Christoph Hellwig
2011-01-28  5:36   ` Dave Chinner
2011-01-28  5:51     ` Dave Chinner
2011-01-28 22:17   ` Alex Elder [this message]
2011-01-21  9:22 ` [PATCH 5/6] xfs: do not classify freed allocation btree blocks as busy Christoph Hellwig
2011-01-28  6:33   ` Dave Chinner
2011-01-28 22:17   ` Alex Elder
2011-02-01 23:02   ` Alex Elder
2011-01-21  9:22 ` [PATCH 6/6] xfs: remove handling of duplicates the busy extent tree Christoph Hellwig
2011-02-01 23:02   ` 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=1296253068.2342.282.camel@doink \
    --to=aelder@sgi.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