Re: [PATCH v4 4/4] btrfs: cap shrink_delalloc iterations to 128M

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2026/4/25 07:51, Qu Wenruo 写道:
> 
> 
> 在 2026/4/25 07:40, Boris Burkov 写道:
>> On Sat, Apr 25, 2026 at 07:36:49AM +0930, Qu Wenruo wrote:
> [...]
>>> At least we got something that both of us can reproduce.
>>>
>>> Another thing is, for g/027 on arm64 I'm also actively monitoring the 
>>> CPU
>>> usage through top.
>>>
>>> Have you experienced very high (~100%) CPU usage on a kworker during 
>>> g/027?
>>>
>>
>> No :(
>> As far as I can tell the system is stuck waiting on a commit. I'll keep
>> trying to repro your symptom.
>>
>> I'm curious if it goes away for you with Sun's proposed fix, something
>> like setting pages to at least 1 after those to min() operations.
> 
> I go with the following diff:
> 
> diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
> index e931deb3d013..2c5214b24239 100644
> --- a/fs/btrfs/space-info.c
> +++ b/fs/btrfs/space-info.c
> @@ -770,6 +770,9 @@ static void shrink_delalloc(struct btrfs_space_info 
> *space_info,
>                  u64 items = calc_reclaim_items_nr(fs_info, 
> iter_reclaim) * 2;
>                  int async_pages;
> 
> +               if (nr_pages == 0)
> +                       nr_pages = 1;
> +
>                  btrfs_start_delalloc_roots(fs_info, nr_pages, true);
> 
>                  /*
> 
> 
> It solves the dead looping kworker on arm64, now the it's several 
> different kworkers taking around 5~15% along with 027 itself taking CPU 
> time.
> 
> But unfortunately the test case itself still seems not to end any time 
> soon.
> 
> I believe the old 3 loops limit is really what makes the difference.
> It's ugly, but at least it seems to work.

Not an expert on the space reclaim part, but as far as I understand, 
there can be some cases where the only dirty folios that can be flushed 
is the folios that are being written back.

E.g. we have a large folio (256KiB) dirty, and that's the only dirty 
data folio in the whole fs.

Then at delalloc time, we are reserving metadata, and we are waiting for 
the ticket to shrink delalloc.

Although the ticket is trying to flush delalloc, the 256KiB dirty folio 
is already under write back, thus it will reclaim no space.
Thus the loop never progresses.

This will cause a semi-deadlock, as we want to reserve metadata to do 
the folio writeback, but the metadata reserving is trying to flush the 
same folio to progress.

And the recent huge folio feature is making the problem more obvious, as 
the folios grow larger, we have higher chance to hit such situation.


With that said, it means delalloc shrinking is never guaranteed to make 
any progress under extreme ENOSPC situation.
Thus a proper way to break out the loop is highly recommended, when 
there is no progress to be done.

Hopes this educated guess would help to explain the problem.

Thanks,
Qu

> 
> Thanks,
> Qu
>