From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 38C78314D1A for ; Fri, 26 Dec 2025 08:31:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766737890; cv=none; b=iF2zP6xSe59RkymG6/CaalSPlAzTMr726fTSqcPKmVYvNlwAcl5BznaYuLFdb38IbCqv0Zhpfn36FCDbUDZw4uw4hEkpSXGQ5C/nGxrkAzcI60XrcC/38mukHhMdLj8nu8i6gEF0xzAwh89IbHY4M8smezVYX2NAE6ElzvM+cto= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766737890; c=relaxed/simple; bh=VC4iXbhpb9DN1t52nro7eZyZqxBig9kYsykmgYHcgqQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MrE82rk6vTYR7WLy8mZUeoTKWKDkeh28XOLCg4V5ZEn+P1ZWs+O8fL583eEU2hKxwz2cXVKbXUIbr5rz+YWI/6/EijvLcWAPPEmXcb1p50rAZ4THZ/Ur/potmQeftYBuYOsEodMd8Bgp/v8+UyLSK0z5on0cSiv88FoZJSnHL5o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=PPgFFT5V; arc=none smtp.client-ip=115.124.30.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="PPgFFT5V" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1766737879; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=6MFpTUQOIiVw73r2AMb2gz8612oplsZa5lGVUR7l7Qo=; b=PPgFFT5Vlwp/Rn3NYafmyQ79tK8axAsDHtRFTVNUJc5em/uE2OeGh+iZcvgGxdKUxDFwbtnA6aXBQN6eTcE5jRmI49Nrnfck8WTkRaqaK4JMmuQ/hUNuI0tJaSlcHFs+FPTCcoE0QQZeq6tlV6D4gG93n1J+QL+DbRo1mOzKcoo= Received: from 30.74.129.66(mailfrom:tongweilin@linux.alibaba.com fp:SMTPD_---0WvgxF.J_1766737878 cluster:ay36) by smtp.aliyun-inc.com; Fri, 26 Dec 2025 16:31:18 +0800 Message-ID: Date: Fri, 26 Dec 2025 16:31:18 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] arm64: Kconfig: enable ARCH_WANTS_THP_SWAP for all pagesizes To: Barry Song <21cnbao@gmail.com> Cc: Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Andrew Morton , David Hildenbrand , linux-mm@kvack.org, baolin.wang@linux.alibaba.com References: <20251226063759.4020782-2-tongweilin@linux.alibaba.com> Content-Language: en-US From: Weilin Tong In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 在 2025/12/26 14:52, Barry Song 写道: > On Fri, Dec 26, 2025 at 7:39 PM Weilin Tong > 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. > > > #ifdef CONFIG_THP_SWAP > #define SWAPFILE_CLUSTER HPAGE_PMD_NR > #define swap_entry_order(order) (order) > #else > #define SWAPFILE_CLUSTER 256 > #define swap_entry_order(order) 0 > #endif Thank you very much for taking the time to review this patch during the holiday. Wishing you a happy holiday as well! I appreciate you pointing out this optimization. We initially noticed the issue because, on ARM64 kernels with 64K page size, if large folios are used in shmem, they cannot be swapped out as a whole during shmem_writeout() due to the config limitation, and are forced to split instead — which is something we wanted to avoid. It seems that this change will help enable better swap operations for large folios. Thank you again for your feedback! >> Signed-off-by: Weilin Tong >> --- >> arch/arm64/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index 93173f0a09c7..58f7b4405f81 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -120,7 +120,7 @@ config ARM64 >> select ARCH_WANT_LD_ORPHAN_WARN >> select ARCH_WANTS_EXECMEM_LATE >> select ARCH_WANTS_NO_INSTR >> - select ARCH_WANTS_THP_SWAP if ARM64_4K_PAGES >> + select ARCH_WANTS_THP_SWAP >> select ARCH_HAS_UBSAN >> select ARM_AMBA >> select ARM_ARCH_TIMER >> -- >> 2.43.7 > Thanks > Barry