From: Dave Chinner <david@fromorbit.com>
To: Alex Elder <aelder@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
Subject: Re: [PATCH 3/6] xfs: do not immediately reuse busy extent ranges
Date: Sat, 29 Jan 2011 11:25:50 +1100 [thread overview]
Message-ID: <20110129002550.GA21311@dastard> (raw)
In-Reply-To: <1296231591.2342.47.camel@doink>
On Fri, Jan 28, 2011 at 10:19:51AM -0600, Alex Elder wrote:
> On Fri, 2011-01-28 at 12:58 +1100, Dave Chinner wrote:
> > On Fri, Jan 21, 2011 at 04:22:30AM -0500, Christoph Hellwig wrote:
> > > Every time we reallocate a busy extent, we cause a synchronous log force
> > > to occur to ensure the freeing transaction is on disk before we continue
> . . .
> > > +
> > > + spin_lock(&pag->pagb_lock);
> > > + rbp = pag->pagb_tree.rb_node;
> > > + while (rbp) {
>
> I will amend the loop termination condition I suggested
> before to be this:
>
> while (rbp && len >= args->minlen) {
Makes sense.
> > > + struct xfs_busy_extent *busyp =
> > > + rb_entry(rbp, struct xfs_busy_extent, rb_node);
> > > + xfs_agblock_t end = bno + len;
> > > + xfs_agblock_t bend = busyp->bno + busyp->length;
> > > +
> > > + if (bno + len <= busyp->bno) {
> > > + rbp = rbp->rb_left;
> > > + continue;
> > > + } else if (bno >= busyp->bno + busyp->length) {
> > > + rbp = rbp->rb_right;
> > > + continue;
> > > + }
> >
> > if (end <= bbno)
> > left;
> > else if (bno > bend)
> > right;
>
> I think the original code is right in this case.
> The value of "bend" is the offset *following* the
> end of the range. So if "bno" equals that, we
> want to move Right. (Same reason <= is correct
> for the first condition here.)
Oops, yes, you are right. Good catch - I failed to copy that code
into psuedo code correctly.
>
> > /* overlap */
> >
> > > +
> > > + if (busyp->bno < bno) {
> > > + /* start overlap */
> > > + ASSERT(bend >= bno);
> > > + ASSERT(bend <= end);
> > > + len -= bno - bend;
> > > + bno = bend;
> >
> > if (bbno < bno) {
> >
> > bbno bend
> > +-----------------+
> > Case 1:
> > +---------+
> > bno end
> >
> > No unbusy region in extent, return failure
>
> Yes, that's right, I missed that. My suggestion goes
> negative in this case.
>
> > Case 2:
> > +------------------------+
> > bno end
> >
> > Needs to be trimmed to:
> > +-------+
> > bno end
> > bno = bend;
> > len = end - bno;
>
> I like defining len in terms of the updated bno as
> you have suggested here.
>
> > > + } else if (bend > end) {
> > > + /* end overlap */
> > > + ASSERT(busyp->bno >= bno);
> > > + ASSERT(busyp->bno < end);
> > > + len -= bend - end;
> >
> . . .
>
>
> > So, it looks to me like the "overlap found" algorithm shoul dbe
> > something like:
>
> For this algorithm, updating the value of len can be done
> once, at the bottom (or top) of the loop, based simply on
> the (updated) value of end and bno:
>
> len = end - bno;
>
> You could rearrange things a bit so this gets done at
> the top--instead of computing the value of end based
> on bno and len.
Quite possibly - I just wanted to enumerate what I though the code
should do rather than present a optimal, completed function ;)
> > if (bbno <= bno) {
> > if (end <= bend) {
> > /* case 1, 3, 5 */
> > return failure;
> > }
> > /* case 2, 6 */
> > bno = bend;
> > len = end - bno;
> > } else if (bend >= end) {
> > ASSERT(bbno > bno);
> > /* case 4, 7 */
> > end = bbno;
> > len = end - bno;
> > } else {
> > ASSERT(bbno > bno);
> > ASSERT(bend < end);
> > /* case 8 */
> > if (bbno - bno >= args->minlen) {
> > /* left candidate OK */
> > left = 1;
> > }
> > if (end - bend >= args->maxlen * 4) {
>
> The "4" here I understand, but it's arbitrary (based
> on an educated guess) so it needs to at least be explained
> here with a comment. Making it symbolic might make it
> something one could search for at some future date.
Yup. That value of "4" was simply a SWAG - I haven't really thought
about the best way to determine if the "remaining free space is much
larger than the allocation request" reliably, but I needed
something there to demonstrate what I was thinking....
....
> > > - if (xfs_alloc_busy_search(mp, agno, fbno, flen)) {
> > > - trace_xfs_discard_busy(mp, agno, fbno, flen);
> > > - goto next_extent;
> > > - }
> > > + xfs_alloc_busy_search_trim(mp, pag, fbno, flen, &tbno, &tlen);
> > >
> > > - trace_xfs_discard_extent(mp, agno, fbno, flen);
> > > + trace_xfs_discard_extent(mp, agno, tbno, tlen);
> > > error = -blkdev_issue_discard(bdev,
> > > - XFS_AGB_TO_DADDR(mp, agno, fbno),
> > > - XFS_FSB_TO_BB(mp, flen),
> > > + XFS_AGB_TO_DADDR(mp, agno, tbno),
> > > + XFS_FSB_TO_BB(mp, tlen),
> > > GFP_NOFS, 0);
> > > if (error)
> > > goto out_del_cursor;
> > > - *blocks_trimmed += flen;
> > > + *blocks_trimmed += tlen;
> >
> > Hmmm - that means if we get a case 8 overlap, we'll only trim one
> > side of the extent. That's probably not a big deal. However, perhaps
> > this should check the size of the trimmed extent before issuing the
> > discard against it in case we've reduced it to something smaller
> > thanthe minimum requested trim size....
>
> I think all of the places that (ultimately) call this function
> need to be looked at to make sure they handle the "error" case
> properly--either checking for a returned error or verifying the
> returned length is at least the minimum.
*nods vigorously*
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-01-29 0:23 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 [this message]
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
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=20110129002550.GA21311@dastard \
--to=david@fromorbit.com \
--cc=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