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@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.
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.