mbox series

[6.10,0/3] btrfs: some fixes/updates for the extent map shrinker

Message ID cover.1720448663.git.fdmanana@suse.com (mailing list archive)
Headers show
Series btrfs: some fixes/updates for the extent map shrinker | expand

Message

Filipe Manana July 8, 2024, 2:42 p.m. UTC
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(-)

Comments

Josef Bacik July 9, 2024, 1:58 p.m. UTC | #1
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

Reviewed-by: Josef Bacik <josef@toxicpanda.com>

Thanks,

Josef
David Sterba July 11, 2024, 3:06 p.m. UTC | #2
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.