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 10317C4345F for ; Thu, 11 Apr 2024 23:01:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 459116B007B; Thu, 11 Apr 2024 19:01:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 408E46B0083; Thu, 11 Apr 2024 19:01:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D0556B0087; Thu, 11 Apr 2024 19:01:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 112246B007B for ; Thu, 11 Apr 2024 19:01:58 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8F988160D56 for ; Thu, 11 Apr 2024 23:01:57 +0000 (UTC) X-FDA: 81998775474.24.7650383 Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by imf06.hostedemail.com (Postfix) with ESMTP id F1398180020 for ; Thu, 11 Apr 2024 23:01:54 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Vy/BLKxW"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.167.169 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712876515; 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=X7Gsq+XB7X2BWSBlXn7jraeh3YIIGyWH+QFowQBTq94=; b=w6N3iASlsooNlp5UtLMND95ztYTS8weBGeSwcuZ6WMbsyiMO74Vpm0VsQAwHHcRoI84WXv GpPvWltdgfGHtGhr9QRfGtI0wnjvHomFZ5hNTR/IcmpSBhO16/y8ve2VTa2UC+XQcsBDhO UFZlEA8hsmeSZVPKxpy7/ZMB0ykB+d4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Vy/BLKxW"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.167.169 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712876515; a=rsa-sha256; cv=none; b=vJtHYhCSMsL6mF7bsASYO3+P4wSFQ9dPTBJUkk3Albo7f1AFBPxFYziO8diRUi+lOffUS5 S45LwxVxQGz+7/ldEtrv7O8ZbfVvQM26IvNgRtZh/DhPQV881YeY05U8ISqApvkdv6HrKh SAygmVu5ertCq0/qU4TBgnppTV+la38= Received: by mail-oi1-f169.google.com with SMTP id 5614622812f47-3c61101874eso115815b6e.1 for ; Thu, 11 Apr 2024 16:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712876514; x=1713481314; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=X7Gsq+XB7X2BWSBlXn7jraeh3YIIGyWH+QFowQBTq94=; b=Vy/BLKxWxOJ1/z+09o3d7cET3aoak3mk/JSTjvujYgQo4QmJMSZhxZIP0MpsLYQlbo Qbyw6xXr5nCpscIzXHuOfz4456Pl/ic9lmcHAQF7D9WS+5mlG8PCFfTEc0gdxYRF4wqD xP+8NA+OQzJkO8rcH/ZUEcie0PP3RiUaDF59llDsbT0cCfka7VStO944w6WVYqP8QRxy OmWh/ewVjwRAxVlFlZbQgdSprCBb/TTaefJGJQ8cptXxV2yHlQXhK3Y9EficW6vyLgu/ vATUvB25KPTr9GGDRbnMncRPufAu5uUoQk9gybZh/WVTaWEhxklQn100JwYL3Myduazh rF4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712876514; x=1713481314; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X7Gsq+XB7X2BWSBlXn7jraeh3YIIGyWH+QFowQBTq94=; b=wr6FHFuUuOZ6ug8Cg7g2rkhjDvLnGY3qQ0TEPq2JNR0B16Qhx0y2RgiDu4V2/+mFYC VhtGyOjTXZjZVbFM96ZVQeii6zwHXkbL81XTiv1CuAg/TEzkwqAfEDVoxPmN6h/iAG4o 9qWOhtWpvKqyTnA/doHLjhLMGJSILr502w/Vvpc2szfwau1buNZABZUDMJm0XPOdjAQ+ DTbcAKxuK9vDWnsWs+N93CMwbyRNrUqjwrBCMq0RRYboohmjy/ZYjH6/Vffh86D4JWst p/NcEQX6l30nRy0djiEqC6W22hIVW0t429+UtAhiQD3NN729FRUalY1kcSwyoAKL6M9y a+gg== X-Forwarded-Encrypted: i=1; AJvYcCWhKLLwfI/WhKA9ek7lhE/hKbUF85WTQgXsfPfmIIoYpO6waCnhnCmZiwqNSaGjosC9rbZLBFe/uBneShiHMnfXSco= X-Gm-Message-State: AOJu0Yzbe3IGO/+aoq49yIkn4Jmk+emVLLBrk6uwJ0gIWeCH8QmZZ19H Ry920qwJq6PdKDmTtUsbYHvf0vYxP8UzA+iDxnowH/3js60Yymi1cdi6nQRoArBy8UJVGEr5Oam dgK3G8Evlrbgy6diB9bZsOkDIfpE= X-Google-Smtp-Source: AGHT+IG8wmZYba6rzxIb/ffT5ygiK4Pd5xPj9Vx2Dfekrl+jvEdQnfMM3W0iGyOC9zFAyIOSha/ihfyImXVapcbJuQw= X-Received: by 2002:a05:6808:1a07:b0:3c6:573:bf3f with SMTP id bk7-20020a0568081a0700b003c60573bf3fmr1458975oib.27.1712876512555; Thu, 11 Apr 2024 16:01:52 -0700 (PDT) MIME-Version: 1.0 References: <20240409082631.187483-1-21cnbao@gmail.com> <20240409082631.187483-6-21cnbao@gmail.com> <226c4935-def2-4d72-b0bb-308578d1e0b1@arm.com> In-Reply-To: <226c4935-def2-4d72-b0bb-308578d1e0b1@arm.com> From: Barry Song <21cnbao@gmail.com> Date: Fri, 12 Apr 2024 11:01:41 +1200 Message-ID: Subject: Re: [PATCH v2 5/5] mm: add per-order mTHP swpin_refault counter To: Ryan Roberts 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, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: F1398180020 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ggw4qhcr39mqgxzoo5ptxq58wg7mj47p X-HE-Tag: 1712876514-401006 X-HE-Meta: U2FsdGVkX1/Rc8mpbMO9CWhaCvemTmvbKYFm/1WsbKaYpeHsShWJUSqW3AOGdCHAMuWccs0rpQlGeLPXl3O6ueUx/1sKLcCo5dh247DEz50BUxME010kB+U6Cp+qZwsqzEu26n/foVOZKYg/T2QnC1RYhCx0AI9P8KwFHh36Lb+ys5qzvW+LTDRM1NjTf8CacIdJpGuCC8GPLI4Kejbu5vCgZ8QCK1cAXnY4f6SSfD02eYdaGgMuhlvbOquWQZtUVE+8oDw0nm6lEItAZ0QF+1RmZL0y/ys9FHR7FV6I3iNPYfF6K9g5ycPhaokWonDi5h6Uudavmd1c2pQa2t9Ls6nZg3Nuo5L8JDyZlRxCRHitJDS6vGVqfnKqat6yHcIV6J/muWksECRsVxowszM0lovM/IyBEpKZj5V57//DcATJ+SKOdT9a6LwIyHojwmpvOnn5VcfgsvTgUBhZkmeZ/jSbxA5e61FupiaZ1Mf7X/SK7HT1qqrnp0wZsblM5Dtt5whj1Lm34236OuO/XhJS9i4nFWV3UCkqBHsNyFkgkiiULu+jdI7uS/a+S+xOQ8XGs8uM+AOuVCENxv45tFhH0FELByhFYzNtCcrRmrTNaOVcJVXiK/RsIDVGsQJLf4gIrJvDnJDYkFCsFrf9pEyKCdPpF9Zt0JxohpZcHsKRrBlGA0IVDLiRyRAHOCP7IrtZ+mRpdEyNA5sT9/eYyTP+89b3G0ejbuxiU//z2XxwGBLg24E/JWaWmp1jABE84niv6XVNnFCF0qLwSXzK1tGEn39IDGjx9oPQArAx/8pmj0IVeZuRPpVgY0saWWLl4EV2BQLJC/cI0z6DheppIB3NHiDHz1YgJRLHIVA+lnj+hlll4S2gwQqcGJ9pjelOy2OWcc2a4cwIA/ikhK56yrfRvuIbUnB00QzHC1QdLQLJRhqGNcQog00lWTwahNIc+qlOlgLRr4PmKpoki6N3dRl SU+aN8Zx BB06e8zsnI2Dn76Vzp4mPf+ICT8uHuRRjTf2tOAGdyG03/nB0A7ysvBFVTnntzLiOQI00PmbG4Nur429os48xZeTDAg== 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 Fri, Apr 12, 2024 at 3:53=E2=80=AFAM Ryan Roberts = wrote: > > 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= ? Indeed, we don't count refaults for small folios, as their refault mechanism is much simpler compared to large folios. Implementing this counter can enhance the system's visibility to users. Personally, having this counter and observing a non-zero value greatly enha= nces my confidence when debugging this refault series. Otherwise, it feels like = being blind to what's happening inside the system :-) > > > __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_FALLBA= CK); > > DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT); > > DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALL= BACK); > > +DEFINE_MTHP_STAT_ATTR(anon_swpin_refault, MTHP_STAT_ANON_SWPIN_REFAULT= ); > > > > 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); > > 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 earl= ier), > but also the folio_test_uptodate() check. Perhaps this should go after th= at? > swap_pte_batch() =3D=3D nr_pages should have passed the test for pte_same. folio_test_uptodate(folio)) should be also unlikely to be true as we are not reading from swap devices for refault case. but i agree we can move all the refault handling after those two "goto out_nomap". > > } > > > > check_pte: > Thanks Barry