On Mon 07-07-25 12:54:56, Zhang Yi wrote:
On 2025/7/4 19:17, Jan Kara wrote:
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.
OK. In my opinion whoever runs with 1k blocksize doesn't really care about performance too much and thus is unlikely to care about getting 2M pages :). But whatever, the limit of 2048 blocks is fine by me.
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))
^^^ PAGE_SHIFT
Otherwise looks good to me.
Honza