All of lore.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/4] xfs: reduce the number of pagb_lock roundtrips in xfs_alloc_clear_busy
Date: Wed, 27 Apr 2011 11:56:21 -0500	[thread overview]
Message-ID: <1303923381.2056.58.camel@doink> (raw)
In-Reply-To: <20110424190657.249817918@bombadil.infradead.org>

On Sun, 2011-04-24 at 15:06 -0400, Christoph Hellwig wrote:
> Instead of finding the per-ag and then taking and releasing the pagb_lock
> for every single busy extent completed sort the list of busy extents and
> only switch betweens AGs where nessecary.  This becomes especially important
> with the online discard support which will hit this lock more often.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

I said this looked good before, but since you haven't
indicated that here yet, I'll make one more comment.

Both places that call (the new) xfs_alloc_busy_clear()
precede the call with a call to xfs_alloc_busy_sort().
Considering that, and the fact that xfs_alloc_busy_clear()
depends on the list being sorted for correct (or at least
efficient) operation, I think you should just embed the
list_sort() call in xfs_alloc_busy_clear().

There would then be no real need to define the
xfs_alloc_busy_sort() helper (just call list_sort()
directly), and you can move the definition of
xfs_busy_extent_ag_cmp() up in the file and give
it private scope.

Perhaps you have other plans that make the model you
have here more appropriate though.  Let me know
if you intend to re-submit, otherwise I'll just take
this version.

Either way, this looks good to me.  I have been
testing with these patches.  I'll wait another day
to give others a chance to review, but I'll plan
to incorporate this tomorrow.

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


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

  reply	other threads:[~2011-04-27 16:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-24 19:06 [PATCH 0/4] improved busy extent handling V5 Christoph Hellwig
2011-04-24 19:06 ` [PATCH 1/4] xfs: optimize AGFL refills Christoph Hellwig
2011-04-29  0:41   ` Dave Chinner
2011-04-24 19:06 ` [PATCH 2/4] xfs: do not immediately reuse busy extent ranges Christoph Hellwig
2011-04-29  0:58   ` Dave Chinner
2011-04-24 19:06 ` [PATCH 3/4] xfs: exact busy extent tracking Christoph Hellwig
2011-04-29  1:10   ` Dave Chinner
2011-04-24 19:06 ` [PATCH 4/4] xfs: reduce the number of pagb_lock roundtrips in xfs_alloc_clear_busy Christoph Hellwig
2011-04-27 16:56   ` Alex Elder [this message]
2011-04-27 19:45     ` Christoph Hellwig
2011-04-29  1:13     ` Dave Chinner
  -- strict thread matches above, loose matches on Subject: below --
2011-04-18  6:59 [PATCH 0/4] improved busy extent handling V4 Christoph Hellwig
2011-04-18  6:59 ` [PATCH 4/4] xfs: reduce the number of pagb_lock roundtrips in xfs_alloc_clear_busy Christoph Hellwig

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