Re: [RFC PATCH] arm64: Kconfig: enable ARCH_WANTS_THP_SWAP for all pagesizes

[Barry Song <21cnbao@gmail.com>]

On Fri, Jan 9, 2026 at 4:32 PM Weilin Tong <tongweilin@linux.alibaba.com> wrote:
>
>
> 在 2026/1/9 07:11, Barry Song 写道:
> > On Fri, Jan 9, 2026 at 7:29 AM Will Deacon <will@kernel.org> wrote:
> >> On Fri, Dec 26, 2025 at 07:52:44PM +1300, Barry Song wrote:
> >>> On Fri, Dec 26, 2025 at 7:39 PM Weilin Tong
> >>> <tongweilin@linux.alibaba.com> wrote:
> >>>> Currently, ARCH_WANTS_THP_SWAP was limited to 4K page size ARM64 kernels, but
> >>>> large folios requiring swapping also exist in other page size configurations
> >>>> (e.g. 64K). Without this config, large folios in these kernels cannot be swapped
> >>>> out.
> >>>>
> >>>> Here we enable ARCH_WANTS_THP_SWAP for all ARM64 page sizes.
> >>> I no longer recall why this was not enabled for sizes other than
> >>> 4 KB in commit d0637c505f8a ("arm64: enable THP_SWAP for arm64"), but
> >>> it appears to be fine, and the swap cluster size should also be
> >>> more friendly to PMD alignment.
> >> You seemed to be worried about I/O latency in your original post:
> >>
> >> https://lore.kernel.org/all/20220524071403.128644-1-21cnbao@gmail.com/
> > Will, thanks for pointing this out! With a 16KB page size, a PMD
> > covers 32MB; with 64KB pages, a PMD covers 512MB. So, Weilin, are
> > we ready to wait for 32MB or 512MB to be written out before
> > memory can be reclaimed? By splitting, we can reclaim memory
> > earlier while only part of it has been swapped out.
>
> I got your point. In our production envs using 64K pagesize kernel, we
> only enable 2M and below size

If mTHP is enabled only for sizes below 2 MB, the patch makes
perfect sense. However, the problem is that we do not know how
others configure their systems.

>
> mthp, so swapping out as a whole is a better way. Or maybe we can set
> the SWAPFILE_CLUSTER by arch.

Even for 512 MB or 32 MB PMD folios, it would be perfectly fine
for SWAPFILE_CLUSTER to match the PMD folio size, given the
assumption that the swap table should be PAGE_SIZE.

>
> I will do some tests of this concern.

Right. It would be helpful to have some test data—for example,
with larger folios like 16 MB, 32 MB, or 64 MB—to see what
happens when memory reclamation kicks in.

One possible option is to call
split_huge_page_to_list_to_order(&folio->page, list,
                                get_order(SZ_2M));

for paging out.But this looks rather ugly :-)

On the other hand, if users configure mTHP to, for example,
128 MB, swapping out and reclaiming the entire 128 MB folio
could actually help with memory de-fragmentation.
So perhaps users should tolerate the I/O latency in this
case?

>
> Thanks a lot.
>
> > While splitting down to order-0 is not ideal, splitting to a
> > relatively larger order appears to strike a balance between I/O
> > latency and swap performance. Anyway, I don't know :-)
> >

Thanks
Barry