Message-ID: <c2dvcablaximwjnwg67spegwkntxjgezu6prvyyto4vjnx6rvh@w3xgx4jjq4bb>
Date: Fri, 4 Jul 2025 13:17:02 +0200
From: Jan Kara <jack@...e.cz>
To: Zhang Yi <yi.zhang@...weicloud.com>
Cc: Naresh Kamboju <naresh.kamboju@...aro.org>, 
	Theodore Ts'o <tytso@....edu>, Jan Kara <jack@...e.cz>, linux-ext4 <linux-ext4@...r.kernel.org>, 
	linux-fsdevel@...r.kernel.org, open list <linux-kernel@...r.kernel.org>, 
	lkft-triage@...ts.linaro.org, Linux Regressions <regressions@...ts.linux.dev>, 
	LTP List <ltp@...ts.linux.it>, Anders Roxell <anders.roxell@...aro.org>, 
	Dan Carpenter <dan.carpenter@...aro.org>, Arnd Bergmann <arnd@...db.de>
Subject: Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle
 with ARM64_64K_PAGES

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

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

Powered by blists - more mailing lists