From: Christoph Hellwig <hch@lst.de>
To: Brian Foster <bfoster@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-xfs@vger.kernel.org, eguan@redhat.com,
darrick.wong@oracle.com
Subject: Re: [PATCH 3/5] xfs: fix bogus minleft manipulations
Date: Sun, 8 Jan 2017 11:36:11 +0100 [thread overview]
Message-ID: <20170108103611.GC26451@lst.de> (raw)
In-Reply-To: <20170104181933.GC41989@bfoster.bfoster>
On Wed, Jan 04, 2017 at 01:19:33PM -0500, Brian Foster wrote:
> Staring at this some more, I'm still not terribly fond of this, moreso
> because I wonder how much more of this can be ripped out
What else do you have in mind?
> and whether the
> low space allocator thing is still effective.
That's a good question. Another item added to my not critical allocator
TODO list, which keeps growing..
> Aside from that, afaict
> the set_aside change should make it robust and addresses my previous
> question in that it holds blocks out of all transaction reservations.
>
> I'm also curious whether the set_aside patch alone addresses the
> original problem, or setting minleft = 0 in one of these cases was
> actually the cause.
I think I needed both changes, but it's been a while and I'll have to
retest.
> > - /*
> > - * Could not find an AG with enough free space to satisfy
> > - * a full btree split. Try again without minleft and if
> > - * successful activate the lowspace algorithm.
> > - */
> > - args.fsbno = 0;
> > - args.type = XFS_ALLOCTYPE_FIRST_AG;
> > - args.minleft = 0;
> > - error = xfs_alloc_vextent(&args);
> > - if (error)
> > - goto error0;
> > - cur->bc_private.b.dfops->dop_low = true;
> > - }
>
> We have a similar retry pattern in xfs_bmap_btalloc() where, in the hunk
> just above, we retain the retry that appears analogous to this one (in
> that it activates the low space algo) and just drop the minleft = 0 bit.
> Here we are dropping the whole thing. Any reason not to be consistent
> one way or the other? (Though do note that we don't check firstblock
> here...).
xfs_bmap_btalloc is a bit different because the alignment question
comes into play as well, in addition to the non-binding AG selection
from the higher level allocator code. But I suspect that there is a lot
of dead or questionable code in it, and it's been on my todo list
to audit xfs_bmap_btalloc, xfs_alloc_vectent and it's subfunction,
and make the argument passing, allocator modes and things like the
lowspace mode aswell as the firstblock magic a lot cleaner and properly
documented.
next prev parent reply other threads:[~2017-01-08 10:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-22 20:00 minleft fixes V2 Christoph Hellwig
2016-12-22 20:00 ` [PATCH 1/5] xfs: bump up reserved blocks in xfs_alloc_set_aside Christoph Hellwig
2017-01-04 14:33 ` Brian Foster
2017-01-08 10:30 ` Christoph Hellwig
2017-01-08 16:07 ` Brian Foster
2016-12-22 20:00 ` [PATCH 2/5] xfs: fix the alignment fallback in xfs_bmap_btalloc Christoph Hellwig
2017-01-04 14:34 ` Brian Foster
2017-01-08 10:31 ` Christoph Hellwig
2017-01-08 16:08 ` Brian Foster
2016-12-22 20:00 ` [PATCH 3/5] xfs: fix bogus minleft manipulations Christoph Hellwig
2017-01-04 18:19 ` Brian Foster
2017-01-08 10:36 ` Christoph Hellwig [this message]
2017-01-08 16:09 ` Brian Foster
2017-01-09 17:56 ` Christoph Hellwig
2016-12-22 20:00 ` [PATCH 4/5] xfs: adjust allocation length in xfs_alloc_space_available Christoph Hellwig
2017-01-04 18:19 ` Brian Foster
2016-12-22 20:00 ` [PATCH 5/5] xfs: don't rely on ->total " Christoph Hellwig
2017-01-04 18:19 ` Brian Foster
2017-01-05 1:21 ` minleft fixes V2 Eryu Guan
2017-01-05 2:01 ` Darrick J. Wong
2017-01-08 10:36 ` Christoph Hellwig
2017-01-08 16:10 ` Brian Foster
2017-01-08 18:10 ` Darrick J. Wong
2017-01-09 15:22 ` Brian Foster
2017-01-09 15:34 ` Christoph Hellwig
2017-01-09 15:43 ` Brian Foster
2017-01-10 4:23 ` Darrick J. Wong
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=20170108103611.GC26451@lst.de \
--to=hch@lst.de \
--cc=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=eguan@redhat.com \
--cc=linux-xfs@vger.kernel.org \
/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.