From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: Improve scalability of busy extent tracking
Date: Thu, 22 Apr 2010 07:01:43 -0400 [thread overview]
Message-ID: <20100422110143.GA21867@infradead.org> (raw)
In-Reply-To: <1271828835-2094-1-git-send-email-david@fromorbit.com>
Having the patches merged into one certainly helps with readability.
This version also passes xfsqa fine while I had some problems with that
with the delayed logging tree.
> o busy extent transaction owner tracked by transaction id, not by
> address of transaction structure. Tracking by address of the
> transaction was triggering false ASSERT failures when searching for
> busy extents with matching start block numbers.
I'm a bit confused by that. How can we ever find a xfs_busy_extent
structure for a transaction that's been freed? We always call
xfs_trans_free_busy before freeing the transaction, so this should
never happen. And if it can happen we can also get a reuse of the tid,
even if it is much more likely. So if there's a corner case I've
missed we really need to keep a pointer to the xlog_ticket and keep
a reference on it as long as we have busy extents belonging to it in
the rbtree.
Besides that here's a few cosmetic comments:
> -STATIC void
> -xfs_alloc_search_busy(xfs_trans_t *tp,
> - xfs_agnumber_t agno,
> - xfs_agblock_t bno,
> - xfs_extlen_t len);
> +static int
> +xfs_alloc_busy_search(struct xfs_mount *mp, xfs_agnumber_t agno,
> + xfs_agblock_t bno, xfs_extlen_t len);
The switch in naming convention looks good to me, but it should
also be applied to xfs_alloc_clear_busy (-> xfs_alloc_busy_clear?)
and xfs_alloc_mark_busy (-> xfs_alloc_busy_add/insert?)
> +xfs_alloc_mark_busy(
> + struct xfs_trans *tp,
> + xfs_agnumber_t agno,
> + xfs_agblock_t bno,
> + xfs_extlen_t len)
> {
> + struct xfs_busy_extent *busyp;
>
> + busyp = kmem_zalloc(sizeof(struct xfs_busy_extent), KM_MAYFAIL);
> + if (!busyp) {
> + /*
> + * No Memory! Since it is now not possible to track the free
> + * block, make this a synchronous transaction to insure that
> + * the block is not reused before this transaction commits.
> + */
> + trace_xfs_alloc_busy(tp, agno, bno, len, 1);
> + xfs_trans_set_sync(tp);
> + return;
> }
>
> + busyp->agno = agno;
> + busyp->bno = bno;
> + busyp->length = len;
> + busyp->tid = xfs_trans_get_tid(tp);
> + INIT_LIST_HEAD(&busyp->list);
>
> + /* trace before insert to be able to see failed inserts */
> + trace_xfs_alloc_busy(tp, agno, bno, len, 0);
> + xfs_alloc_busy_insert(tp, busyp);
> +}
I'd rather inline xfs_alloc_busy_insert into this function, there's no
good reason to keep it separate.
> - xfs_trans_clear_busy_extents(tp);
> + xfs_trans_free_busy(tp->t_mountp, &tp->t_busy);
> xfs_trans_free(tp);
> }
>
> @@ -1013,7 +1016,7 @@ xfs_trans_uncommit(
> xfs_trans_unreserve_and_mod_dquots(tp);
>
> xfs_trans_free_items(tp, flags);
> - xfs_trans_free_busy(tp);
> + xfs_trans_free_busy(tp->t_mountp, &tp->t_busy);
There's no real need for the prototype change at this point. I know
you'll need it for the delayed logging, but let's keep the prototype
change in that patchset.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-04-22 10:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-21 5:47 [PATCH] xfs: Improve scalability of busy extent tracking Dave Chinner
2010-04-22 11:01 ` Christoph Hellwig [this message]
2010-04-22 16:16 ` Dave Chinner
2010-04-22 17:08 ` Christoph Hellwig
2010-04-23 3:24 ` Dave Chinner
2010-04-22 11:07 ` Christoph Hellwig
2010-04-22 17:10 ` Christoph Hellwig
2010-04-23 3:25 ` Dave Chinner
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=20100422110143.GA21867@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