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 4080EC4345F for ; Wed, 17 Apr 2024 01:40:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A80026B0083; Tue, 16 Apr 2024 21:40:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A304F6B0089; Tue, 16 Apr 2024 21:40:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F8686B008C; Tue, 16 Apr 2024 21:40:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 70BFF6B0083 for ; Tue, 16 Apr 2024 21:40:30 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id DAD441604B8 for ; Wed, 17 Apr 2024 01:40:29 +0000 (UTC) X-FDA: 82017318978.14.81816FE Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) by imf20.hostedemail.com (Postfix) with ESMTP id 2E9EA1C0006 for ; Wed, 17 Apr 2024 01:40:26 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fY2XGZHX; spf=pass (imf20.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.14 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713318027; 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:dkim-signature; bh=kJAChD8ilY6SHR+97RKxAvxjYsZ6Npt8RNfJAEj/0Fo=; b=h0YmKuljWOdNbPnObSVs8IWVi4ZmyN6gnyXxf6g/yshAwjvToDJO3zMZ9w4ueDSufNaF65 GUjMPtQURT+L6cIAzmzcqA1TGSHwssLcPlilVtLzHLedzNvm3jVb+RjKU3O7OeHhmW+S/6 MV0o8ZNnFF2e8g3XZVWtWHGTujC+dAQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713318027; a=rsa-sha256; cv=none; b=8ZbEoCJ/OtdCHl4bHJ/IwTY6EsDE45qHJO+xRLTukJ5XCikRTSIY5g91WiZMzNO9p3ab1Y Ld6Y8Ke+gcEHokJs0L16+4tXVVO2hP6tVU12PeAB8mbxJ71kWcPBUk+7rdW7/lPtsOBNGP OUYtcUKsoMusqmKU7/xaiAydJOBjsLk= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fY2XGZHX; spf=pass (imf20.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.14 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1713318027; x=1744854027; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=IeBGe3MQxZXvfL2tvMUmEd6ECEsTggUCdjsGjqXHtTc=; b=fY2XGZHXR1GJC/ZDWbnhk8k0kAU05PkxctjigKujjiVwYC6P9j61RXLq YR8adKpuVOR51PQOxmdE0y9u80F+jAyQA1u3GA1ggYfBBJCEzribwVahl VpgxbagxEF1o4Z4OsNNyriiDgtAXGOH+vsmKQUW5mZWKZfVesk8ndKjzQ RTPUAJ6/nWQwrxWTBKZ4sA3wbihDO/yzoeo8PxC4/zuOXsvcwGJUM3xRp qCe9cSeksLXO/w5XzNy5f70T9yN/delLyKaB7c+xPWmjAG8Cupfd1T0Qh 439SxQLFHSeguFP5JHHXOz60LjRH8RRSnSsKgWof9QsmgLq/LQyPC2o1n w==; X-CSE-ConnectionGUID: 2OmUgtnpTtu12TuTbf92Sg== X-CSE-MsgGUID: uchAfbgTSDyF9yrlQUyOdQ== X-IronPort-AV: E=McAfee;i="6600,9927,11046"; a="9011218" X-IronPort-AV: E=Sophos;i="6.07,207,1708416000"; d="scan'208";a="9011218" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2024 18:40:20 -0700 X-CSE-ConnectionGUID: J5h0IzEuSx634XtdGIUREw== X-CSE-MsgGUID: eaFEIr0XRHmCki3nsnUJiA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,207,1708416000"; d="scan'208";a="22932664" Received: from unknown (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2024 18:40:15 -0700 From: "Huang, Ying" To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hanchuanhua@oppo.com, hannes@cmpxchg.org, hughd@google.com, kasong@tencent.com, ryan.roberts@arm.com, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, xiang@kernel.org, yosryahmed@google.com, yuzhao@google.com, ziy@nvidia.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 5/5] mm: add per-order mTHP swpin_refault counter In-Reply-To: (Barry Song's message of "Wed, 17 Apr 2024 09:16:01 +0800") References: <20240409082631.187483-1-21cnbao@gmail.com> <20240409082631.187483-6-21cnbao@gmail.com> <87frvk24x8.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Wed, 17 Apr 2024 09:38:22 +0800 Message-ID: <87bk6822gh.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2E9EA1C0006 X-Stat-Signature: xyo8kafz4o93g3zkadp4u37qafmdpmps X-HE-Tag: 1713318026-966154 X-HE-Meta: U2FsdGVkX18UvKY8jUxI8S7/aKUR1550d8GbXEpbMXwko1OwGdy6RlukX5PhlUOfCTHrf4h0eMs3vnmujf0vFF1KbH0Si0uPyHo4PbRkHqyjHFTmwxN6RSeo+UTJFc0B1U5mPSG23F1S3ohHDRKuuL0CQt9BWIh7thfk5n8yYGQxSyh+1RxK6zyUVkzkI2FznxVAwF83yavwKY/O9ud9CUpTJVGSChjJdefCvxzbFFDTWj30nTqXmJiuNaZ8IDOqNeBAIwiEQ+gYj9/EsfmR4Q1xLC9mbHoBo0j40Q3GUvgSTJ3v1zuScb4lz0eisLCzSxeeGbQoLfIxjJ9rEr+bJZ1j+GgI0kx5a7cqeTiYT93vLRyMiuQdxL4uH1dWJExt1ZiKgwKK6BlvZERPgVVYAsQ6maBjukbhtFLYG/PiNoW+5W9pJEe410SYFs8f3bcR45lDNwcZ3MvUOFjxTAMAztdsscCb/TufS8sIC3wUfq/z3exyykiISPezuwj0ZmA/7EMH1TimPBz6CV1IXVjXIGBgwOqfRH5f/7Ugja1OsKlfsCQ+xzn++LEfSiQGwbhAmgOTF3eE1GAx/Q+bQGVZcigMUpfY65xF9ILf9zQ5/Pvzojx37GrUDvamhVSjP/Vc1R37vbR+r7fS8FGZhk54aVYx7Su4VGOYeu90LNmDuoGOuTpZVEM4d+vjqBBjye/y48yJgfQ3ROhGed9qmMTRD27vk74G9WS+FSQccAiWMzXLUPrNd2I3oWzY7ywUOkt5EpTOAWVBDiwKxemUaj1MWLHbu+sVoO/8FTyfzbcVPFaAFy6jyRjNmMy7/C5SoG6L4XJBgYxLs12F6ylb9P7PEExdU8wk8MWtDCubRFABepOfDVP9jEHJI3DNqFZcN+62bBwuHnLtnkzRp0PcFvTCnGqugFRvY/fFKTlJUY7f1ed0Gu4dhsgwcqRrCXxzwn4Djatiugi9ZW6XIRSyqID As0k56ea BogekYaGhr/slZEmWbDCOVU0+MCxuJsNOTCaw+VCqZTs3Cwa3QcWSJM+1fCv1CcWjVTvY9Giq4kF21yBHAv4nNLEaWK2VDJ5nJW9wpCmym16b3XP2u2Zi6rsVbhDphkoFvXGRN/MSMC1EYENSura1A2FLlfnA5tJ5iqSXFrtIDYEhMIUOtYXAgg/ErnrscDkr9a0zfDgO1Ysd5c1ocwXV1amJ/b4dwpsksQjh825WQ3jvRPqntXLJ0iNAMVAm5PdVaJJ6066dfj5SA+wfnAEQbnrBVdrSP/3tCSPDEozNtO3Nm3aZijfy74+kScW5eoSmSrv3MeGQDk1F8C4= 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: Barry Song <21cnbao@gmail.com> writes: > On Wed, Apr 17, 2024 at 8:47=E2=80=AFAM Huang, Ying wrote: >> >> Barry Song <21cnbao@gmail.com> writes: >> >> > 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, >> >> This is different from the refault concept used in other place in mm >> subystem. Please check the following code >> >> if (shadow) >> workingset_refault(folio, shadow); >> >> in __read_swap_cache_async(). > > right. it is slightly different as refault can also cover the case folios > have been entirely released and a new page fault happens soon > after it. > Do you have a better name for this? > MTHP_STAT_ANON_SWPIN_UNDER_RECLAIM > or > MTHP_STAT_ANON_SWPIN_RECLAIMING ? TBH, I don't think we need this counter. It's important for you during implementation. But I don't think it's important for end users. -- Best Regards, Huang, Ying >> >> > __MTHP_STAT_COUNT >> > }; >> >> -- >> Best Regards, >> Huang, Ying >> >> > 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_FALLB= ACK); >> > DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT); >> > DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FAL= LBACK); >> > +DEFINE_MTHP_STAT_ATTR(anon_swpin_refault, MTHP_STAT_ANON_SWPIN_REFAUL= T); >> > >> > static struct attribute *stats_attrs[] =3D { >> > &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 =3D nr; >> > entry =3D folio->swap; >> > page =3D &folio->page; >> > + count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN= _REFAULT); >> > } >> > >> > check_pte: