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

[Jan Kara]

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
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR