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@huaweic...
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.
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...
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().
Honza