[LTP] next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Zhang Yi]

On 2025/7/4 19:17, Jan Kara wrote:
> On Thu 03-07-25 19:33:32, Zhang Yi wrote:
>> On 2025/7/3 15:26, Naresh Kamboju wrote:
>>> On Thu, 26 Jun 2025 at 19:23, Zhang Yi <yi.zhang@huaweicloud.com> wrote:
>>>> On 2025/6/26 20:31, Naresh Kamboju wrote:
>>>>> Regressions noticed on arm64 devices while running LTP syscalls mmap16
>>>>> test case on the Linux next-20250616..next-20250626 with the extra build
>>>>> config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
>>>>>
>>>>> Not reproducible with 4K page size.
>>>>>
>>>>> Test environments:
>>>>> - Dragonboard-410c
>>>>> - Juno-r2
>>>>> - rk3399-rock-pi-4b
>>>>> - qemu-arm64
>>>>>
>>>>> Regression Analysis:
>>>>> - New regression? Yes
>>>>> - Reproducibility? Yes
>>>>>
>>>>> Test regression: next-20250626 LTP mmap16 WARNING fs jbd2
>>>>> transaction.c start_this_handle
>>>>>
>>>>> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>>>>
>>>> Thank you for the report. The block size for this test is 1 KB, so I
>>>> suspect this is the issue with insufficient journal credits that we
>>>> are going to resolve.
>>>
>>> I have applied your patch set [1] and tested and the reported
>>> regressions did not fix.
>>> Am I missing anything ?
>>>
>>> [1] https://lore.kernel.org/linux-ext4/20250611111625.1668035-1-yi.zhang@huaweicloud.com/
>>>
>>
>> Hmm. It seems that my fix for the insufficient journal credit series
>> cannot handle cases with a page size of 64k. The problem is the folio
>> size can up to 128M, and the 'rsv_blocks' in ext4_do_writepages() can
>> up to 1577 on 1K block size filesystems, this is too large.
> 
> Firstly, I think that 128M folios are too big for our current approaches
> (in ext4 at least) to sensibly work. Maybe we could limit max folio order
> in ext4 mappings to max 1024 blocks per folio or something like that? For
> realistic setups with 4k blocksize this means 4M folios which is not really
> limiting for x86. Arm64 or ppc64 could do bigger but the gain for even
> larger folios is diminishingly small anyway.

Yeah, I agree.

> 
> Secondly, I'm wondering that even with 1577 reserved blocks we shouldn't
> really overflow the journal unless you make it really small. But maybe
> that's what the test does...

Yes, the test creates a filesystem image with a block size of 1 KB and a
journal consisting of 1024 blocks.

> 
>> Therefore, at this time, I think we should disable the large folio
>> support for 64K page size. Then, we may need to reserve rsv_blocks
>> for one extent and implement the same journal extension logic for
>> reserved credits.
>>
>> Ted and Jan, what do you think?
> 
> I wouldn't really disable it for 64K page size. I'd rather limit max folio
> order to 1024 blocks. That actually makes sense as a general limitation of
> our current implementation (linked lists of bhs in each folio don't really
> scale). We can use mapping_set_folio_order_range() for that instead of
> mapping_set_large_folios().
> 

Indeed, after noticing that Btrfs also calls mapping_set_folio_order_range()
to set the maximum size of a folio, I thought this solution should work. So
I changed my mind and was going to try this solution. However, I guess limit
max folio order to 1024 blocks is somewhat too small. I'd like to limit the
order to 2048 blocks, because this this allows a file system with a 1KB
block size to achieve a maximum folio size to PMD size in x86 with a 4KB
page size, this is useful for increase the TLB efficiency and reduce page
fault handling overhead.

I defined a new macro, something like this:

/*
 * Limit the maximum folio order to 2048 blocks to prevent overestimation
 * of reserve handle credits during the folio writeback in environments
 * where the PAGE_SIZE exceeds 4KB.
 */
#define EXT4_MAX_PAGECACHE_ORDER(i)             \
                min(MAX_PAGECACHE_ORDER, (11 + (i)->i_blkbits - PAGE_SIZE))

What do you think?

Best regards,
Yi.