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

[Weilin Tong]

在 2026/1/9 07:11, Barry Song 写道:
> On Fri, Jan 9, 2026 at 7:29 AM Will Deacon <will at 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 at 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

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

I will do some tests of this concern.

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