From: David Sterba <dsterba@suse.cz>
To: fdmanana@kernel.org
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 6.10 0/3] btrfs: some fixes/updates for the extent map shrinker
Date: Thu, 11 Jul 2024 17:06:07 +0200 [thread overview]
Message-ID: <20240711150607.GC8022@twin.jikos.cz> (raw)
In-Reply-To: <cover.1720448663.git.fdmanana@suse.com>
On Mon, Jul 08, 2024 at 03:42:42PM +0100, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> A few fixes for the extent map shrinker that fix some reports from users
> where their desktops became very unresponsive.
>
> Several notes here:
>
> 1) The first patch was already sent before to the list and it's in
> for-next already. It's unrelated to the reports from those users but
> it's related to a report from syzbot for a deadlock in case the
> shrinker does an iput on an inode with 0 links that needs to be
> deleted, and when the inode still has links but it's dirty, it can
> make the iput wait for writeback to complete, slowing down the
> shrinker. I've included it here just to group things in a logical
> way;
>
> 2) These patches apply to 6.10-rc;
>
> 3) At least the first 2 patches should go to 6.10 final IMO;
>
> 4) In case they land in 6.10-rc, then for-next needs to be rebased since
> there are minor and trivial conflicts to solve due to the last patch in
> for-next that reduces the size of struct btrfs_inode down to 1024 bytes.
>
> Also the following patch which landed on for-next should be dropped
> because it's made obsolete by the second patch in this patchset:
>
> https://lore.kernel.org/linux-btrfs/cb12212b9c599817507f3978c9102767267625b2.1719825714.git.fdmanana@suse.com/
>
> 5) There will be further improvements to the shrinker, namely to
> reduce the latency of finding open inodes in a root, but those
> will come later and may be too much for 6.10 final. It would also
> require different patch versions for 6.10 and 6.11 (for-next) since
> in the former we use a rbtree while in the later we have a xarray
> now.
>
> Thanks.
>
> Filipe Manana (3):
> btrfs: use delayed iput during extent map shrinking
> btrfs: stop extent map shrinker if reschedule is needed
> btrfs: avoid races when tracking progress for extent map shrinking
Thanks for the fixes, this seems to be urgent, I'd rather not delay
getting the fixes via stable with a 2 week delay. I'm going to send a
pull request for 6.10, the problems have been reported by early testing
users and will be most likely seen by more after release.
I hope this gives it enough justification despite the patch sizes and
ETA of 6.10 release.
prev parent reply other threads:[~2024-07-11 15:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-08 14:42 [PATCH 6.10 0/3] btrfs: some fixes/updates for the extent map shrinker fdmanana
2024-07-08 14:42 ` [PATCH 1/3] btrfs: use delayed iput during extent map shrinking fdmanana
2024-07-08 14:42 ` [PATCH 2/3] btrfs: stop extent map shrinker if reschedule is needed fdmanana
2024-07-08 14:42 ` [PATCH 3/3] btrfs: avoid races when tracking progress for extent map shrinking fdmanana
2024-07-09 13:58 ` [PATCH 6.10 0/3] btrfs: some fixes/updates for the extent map shrinker Josef Bacik
2024-07-11 15:06 ` David Sterba [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=20240711150607.GC8022@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@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