From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (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 7C575346772 for ; Fri, 9 Jan 2026 08:32:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767947540; cv=none; b=TfsCA5SQfxquFLQDkHzQ2jOVjeJKz1RsIxCnzRxwIr20XdcXm1qfBTsUtt9twOXeM33zhjn+n4T90uT8iETyNMLP2f+SATcGVLLPEgHvI1HfofXisBZu76+myCf4Y924X3adUSgfbJVfQ9XR9Gn/uSqPvCC9pHbbjGIwIORjFWo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767947540; c=relaxed/simple; bh=+nmQmBM2GjLXxU3zmpTGwNRHEX3df2f57e6g2mDI4dk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qyGQhOXjuJ2poPjeb2zQxvuRkXnaidm4z5jwPSBgGcwWP0q/FirJOOX9Y7OpWw6k6IM1HOKwAdjJIPUzuD6SCLUE5wojuXHyp8tCCCURo6IM9FG7eHLG/rmlsHm/oZO2KMHbiukxhUF9JywfoQNtIsINQrzygSFlGmFBMQD0jqs= 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=Veo0C+dD; arc=none smtp.client-ip=115.124.30.124 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="Veo0C+dD" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1767947534; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=H5FICVbCdpL28fxRZxhccvb+qo60S0uzBKWHTrHtW50=; b=Veo0C+dDCsHdZty2i523QGwXgRTLZI8rmOGIhYd+jA813qulU7NdnzkvKZFz53Sgz7rVz8T4e4G1Pep6O8wCfXxej68cPL0TBJpTOHBHkUxwBLS4nBGDAM0zA5duh0jc7W3tFldefw8lvMZtnGQmBMUqswTjP09nyuKlU6c2Pso= Received: from 30.74.129.18(mailfrom:tongweilin@linux.alibaba.com fp:SMTPD_---0WwgBVo0_1767947533 cluster:ay36) by smtp.aliyun-inc.com; Fri, 09 Jan 2026 16:32:13 +0800 Message-ID: Date: Fri, 9 Jan 2026 16:32:12 +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>, Will Deacon Cc: Catalin Marinas , 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 在 2026/1/9 07:11, Barry Song 写道: > On Fri, Jan 9, 2026 at 7:29 AM Will Deacon 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 >>> 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