From: Weilin Tong <tongweilin@linux.alibaba.com>
To: Barry Song <21cnbao@gmail.com>, Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
linux-mm@kvack.org, baolin.wang@linux.alibaba.com
Subject: Re: [RFC PATCH] arm64: Kconfig: enable ARCH_WANTS_THP_SWAP for all pagesizes
Date: Fri, 9 Jan 2026 16:32:12 +0800 [thread overview]
Message-ID: <f9d1c2d2-a6d9-47b7-9f1d-382a28bb88b8@linux.alibaba.com> (raw)
In-Reply-To: <CAGsJ_4waQsxPKTcGvtpTAF4kVbYQXeH_iHaQX3aAYDNo-8oDLQ@mail.gmail.com>
在 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
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
next prev parent reply other threads:[~2026-01-09 8:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-26 6:38 Weilin Tong
2025-12-26 6:52 ` Barry Song
2025-12-26 8:18 ` Weilin Tong
2025-12-26 8:31 ` Barry Song
2025-12-26 8:40 ` Weilin Tong
2025-12-26 8:31 ` Weilin Tong
2026-01-08 18:29 ` Will Deacon
2026-01-08 23:11 ` Barry Song
2026-01-09 8:32 ` Weilin Tong [this message]
2026-01-09 9:59 ` Barry Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f9d1c2d2-a6d9-47b7-9f1d-382a28bb88b8@linux.alibaba.com \
--to=tongweilin@linux.alibaba.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox