linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: don't reuse busy extents on extent trim
Date: Thu, 25 Feb 2021 13:05:24 -0500	[thread overview]
Message-ID: <YDfm5Cl/ZJe6TkH6@bfoster> (raw)
In-Reply-To: <20210225075105.GG2483198@infradead.org>

On Thu, Feb 25, 2021 at 07:51:05AM +0000, Christoph Hellwig wrote:
> As a quick fix this looks good:
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> 
> That beeing said we really need to go back and look into this,
> especially due to discards.  For SSDs it is generlly much better to
> quickly reuse freed blocks rather than discarding them later.
> 

Ok, that's an interesting point. I'm not sure online discard is a super
critical use case, but I agree that there's a tangible advantage to
optimizing out pending discards in that configuration.

That also raises a caveat with the alternative implementation I was
mulling over. The current implementation simply skips over extents that
are busy and already under discard. If we were to find a prospective
reusable busy block (not under discard), allocate it, and then commit to
reusing it, we'd have to deal with the fact that we could find it under
discard at that point. We can't easily skip it because we've already
performed an allocation in the transaction by that point. I suspect the
simplest solution is just wait for the discard to complete since we
already have somewhat of a mechanism to do that, but hopefully it
wouldn't be a frequent occurence.

Brian


      reply	other threads:[~2021-02-25 18:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 15:34 [PATCH] xfs: don't reuse busy extents on extent trim Brian Foster
2021-02-22 18:27 ` Darrick J. Wong
2021-02-23 12:31   ` Brian Foster
2021-02-23 18:22     ` Darrick J. Wong
2022-05-26 11:34     ` Amir Goldstein
2022-05-26 14:21       ` Brian Foster
2022-05-26 15:28         ` Amir Goldstein
2022-05-26 19:33           ` Amir Goldstein
2022-05-26 19:47           ` Brian Foster
2022-05-26 20:56             ` Amir Goldstein
2022-05-27  7:06               ` Amir Goldstein
2022-05-27 12:50                 ` Brian Foster
2022-05-27 14:16                   ` Amir Goldstein
2022-05-28 14:23             ` Amir Goldstein
2022-05-31 15:55               ` Brian Foster
2023-01-11 14:41       ` Gao Xiang
2023-01-11 21:06         ` Dave Chinner
2021-02-23  6:24 ` Chandan Babu R
2021-02-25  7:51 ` Christoph Hellwig
2021-02-25 18:05   ` Brian Foster [this message]

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=YDfm5Cl/ZJe6TkH6@bfoster \
    --to=bfoster@redhat.com \
    --cc=hch@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).