From: fdmanana@kernel.org
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 6.10 0/3] btrfs: some fixes/updates for the extent map shrinker
Date: Mon, 8 Jul 2024 15:42:42 +0100 [thread overview]
Message-ID: <cover.1720448663.git.fdmanana@suse.com> (raw)
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
fs/btrfs/disk-io.c | 2 +
fs/btrfs/extent_map.c | 123 ++++++++++++++++++++++++++---------
fs/btrfs/fs.h | 1 +
include/trace/events/btrfs.h | 18 ++---
4 files changed, 107 insertions(+), 37 deletions(-)
--
2.43.0
next reply other threads:[~2024-07-08 14:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-08 14:42 fdmanana [this message]
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
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=cover.1720448663.git.fdmanana@suse.com \
--to=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