From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CA6DC4345F for ; Thu, 11 Apr 2024 15:53:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D0DE16B0085; Thu, 11 Apr 2024 11:53:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C979A6B0095; Thu, 11 Apr 2024 11:53:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B0FE46B0096; Thu, 11 Apr 2024 11:53:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9127D6B0085 for ; Thu, 11 Apr 2024 11:53:49 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E91E41C0455 for ; Thu, 11 Apr 2024 15:53:48 +0000 (UTC) X-FDA: 81997696536.13.5B41868 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf05.hostedemail.com (Postfix) with ESMTP id 6984D10001E for ; Thu, 11 Apr 2024 15:53:46 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712850826; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3fOdbGaiVwfs1TZoAU6p7XRIthTIKEyh9FiBphkcNtE=; b=0scW02YcR5pXXtt4znT8rI2xrgkDzmvy/rBJxo6ehs4D/47Zj3dE85QHZiA7KEScb1lfWe /cpFSzzeeWDS1An/EeODc/daumfkgTyJxd3fUs2H5lhzf5pqyuQaybpKL0Rgp1XuwSutSu Q9dDygoK/GVLQPJ9e3uWjFe49Iab3YU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712850826; a=rsa-sha256; cv=none; b=5HeEjf62UZ/wWSuUI/DOgWKBIaQh0KgpAGfcPKniFMYOVUjjfeDeEIHg1k2bvGyb8PyhqO cvpfDa3RHYt4SSJy/+7wqpLejdQ9GW+LhHy5YoCfEVboGiL/7La2llYR4VFP+DnoKO4+a+ 3xlprDN9rBlqhl0J/JX92htUL17uo5c= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 07E13113E; Thu, 11 Apr 2024 08:54:15 -0700 (PDT) Received: from [10.1.38.151] (XHFQ2J9959.cambridge.arm.com [10.1.38.151]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 47CDE3F6C4; Thu, 11 Apr 2024 08:53:43 -0700 (PDT) Message-ID: <226c4935-def2-4d72-b0bb-308578d1e0b1@arm.com> Date: Thu, 11 Apr 2024 16:53:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/5] mm: add per-order mTHP swpin_refault counter Content-Language: en-GB To: Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org Cc: baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hanchuanhua@oppo.com, hannes@cmpxchg.org, hughd@google.com, kasong@tencent.com, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yosryahmed@google.com, yuzhao@google.com, ziy@nvidia.com, linux-kernel@vger.kernel.org References: <20240409082631.187483-1-21cnbao@gmail.com> <20240409082631.187483-6-21cnbao@gmail.com> From: Ryan Roberts In-Reply-To: <20240409082631.187483-6-21cnbao@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6984D10001E X-Rspam-User: X-Stat-Signature: 4ar56w8z99bit1quyutryjgm8shckbrq X-Rspamd-Server: rspam03 X-HE-Tag: 1712850826-234940 X-HE-Meta: U2FsdGVkX1/6OvD2JfvWwNjyC79J7+Ggfs/Tle7NecJXp9CsVKU3stULVNqD3YgwD7KVIWEYXRDejnznFZpQtiFf0fslU51SMbuTSv5nX6bMoR6w0jL4QKWhmwnBunIiQOhpdU5BIMnI2GZGohdfoNfJzMlOvtY21rzZLyaa0FyaTD53mtgNeD3XvN/z4edIykRLNweFwYfiFCRAh+I4vw4MdLBueykg2XYb3wV6Hn9NDsda16MpfNRMYE4FlSI+xL/ZyYV2p9jX31B0TrosM2rf/Ykz4O6pPqaJJ6lKwEFAaCNBRcFimWqhJHEGSY4mWobIePvJcWXujixXvz5KbxwgsRgw68bzBik8kd6b6A61MtRd4UFYGsYS02gx37vsjpBozOLrGw8cISDs2mFQw+N7yeON5/19PJftKZmWYkGq42C5WzFf/hiSIt9/1oQwXMjvZ8hLfdXqJ7sYVg5tbqUo+KpXPGJa6p9Qaw8Nc13EoDM75PMP1KsolG8TNu++lCQdbF/WDwbLBfLfGUs8Jj1pOyN0XwLYguDj7E4vuuDa53JrC6MV5GBskFt45kjf4SQ3BbF62Rn3RV1egxYAS8Q28+pT0LQJW8ptIwkFtxLPMVhBM3iCZ/AY8KbzblaebDUds+/+44/Bkt9c+EZdR+rTIgsB29G02A1wufqhHhFl52s4rrvGbtfA3BsOpgrELFZv+4khTmBG3N+cUNE99H485PavqUFUZXa13u1633chkmqSxUm1gpuX+V/4F5m2eRgwnhESxT6KsP+advoUSrrzJnRpOiSQ0zFSK3K5MmG17opXRvvT9PknXbZHf9MphUnaSoIvGaFldfbHe9U6OKQClpkRchJMbfjiUc+yHoi1qxvk5pQW1QTHJxe8sn67dyQBhSqSWBE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 09/04/2024 09:26, Barry Song wrote: > From: Barry Song > > Currently, we are handling the scenario where we've hit a > large folio in the swapcache, and the reclaiming process > for this large folio is still ongoing. > > Signed-off-by: Barry Song > --- > include/linux/huge_mm.h | 1 + > mm/huge_memory.c | 2 ++ > mm/memory.c | 1 + > 3 files changed, 4 insertions(+) > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > index c8256af83e33..b67294d5814f 100644 > --- a/include/linux/huge_mm.h > +++ b/include/linux/huge_mm.h > @@ -269,6 +269,7 @@ enum mthp_stat_item { > MTHP_STAT_ANON_ALLOC_FALLBACK, > MTHP_STAT_ANON_SWPOUT, > MTHP_STAT_ANON_SWPOUT_FALLBACK, > + MTHP_STAT_ANON_SWPIN_REFAULT, I don't see any equivalent counter for small folios. Is there an analogue? > __MTHP_STAT_COUNT > }; > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index d8d2ed80b0bf..fb95345b0bde 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -556,12 +556,14 @@ DEFINE_MTHP_STAT_ATTR(anon_alloc, MTHP_STAT_ANON_ALLOC); > DEFINE_MTHP_STAT_ATTR(anon_alloc_fallback, MTHP_STAT_ANON_ALLOC_FALLBACK); > DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT); > DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALLBACK); > +DEFINE_MTHP_STAT_ATTR(anon_swpin_refault, MTHP_STAT_ANON_SWPIN_REFAULT); > > static struct attribute *stats_attrs[] = { > &anon_alloc_attr.attr, > &anon_alloc_fallback_attr.attr, > &anon_swpout_attr.attr, > &anon_swpout_fallback_attr.attr, > + &anon_swpin_refault_attr.attr, > NULL, > }; > > diff --git a/mm/memory.c b/mm/memory.c > index 9818dc1893c8..acc023795a4d 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -4167,6 +4167,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > nr_pages = nr; > entry = folio->swap; > page = &folio->page; > + count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT); I don't think this is the point of no return yet? There's the pte_same() check immediately below (although I've suggested that needs to be moved to earlier), but also the folio_test_uptodate() check. Perhaps this should go after that? > } > > check_pte: