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 7A291C10F1A for ; Tue, 7 May 2024 08:26:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 131A26B00A2; Tue, 7 May 2024 04:26:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E1036B00A3; Tue, 7 May 2024 04:26:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EEB356B00A4; Tue, 7 May 2024 04:26:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D15F56B00A2 for ; Tue, 7 May 2024 04:26:49 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8695E1C0510 for ; Tue, 7 May 2024 08:26:49 +0000 (UTC) X-FDA: 82090918938.05.9E43FFD Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf25.hostedemail.com (Postfix) with ESMTP id 89F37A0005 for ; Tue, 7 May 2024 08:26:47 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="XI/VNQol"; spf=pass (imf25.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715070407; 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=4ABsOP8SEu68sVFLiASZm/u0Hmy8w+mAVpH8nCUwY0A=; b=kmBq+LwGmEKukufF83yHkKdP0FmOh0hw8kmnUM/JH5V3CEXgOMqn2Qzt8t29XBlvs5ztgF 9qxxCdbog8vhqnVmvyNdE3GSH5tpWzhhM40gxKzqMluzXWsX3f+5HiA5YHO4FSDc65vO0D +fnezxbtrgZd11LZMBdTJr44knA9ZB0= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="XI/VNQol"; spf=pass (imf25.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715070407; a=rsa-sha256; cv=none; b=d1yRsaduuUp/06C+DIwjMiUZitybmfb/NDRo58bgme4TKn1d8eMUyQWoXyj4+1NoYqKhCW 62T6hhzNxualek8ycE6Vy5vJVoa8i8y0RsU8xKCmnFzOK7xGaqo6WuZ6IMYNzaT+xvlwKH U4Apjz0VsKUApZ2PuCnjj4MOBuWeip8= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a59a8f0d941so729973966b.2 for ; Tue, 07 May 2024 01:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715070406; x=1715675206; 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=4ABsOP8SEu68sVFLiASZm/u0Hmy8w+mAVpH8nCUwY0A=; b=XI/VNQolxcmnV8G36T8nNYcb4wxtbdjWTUfgTyX9kPntWnNkUcatoSZnaXlFRU/rk2 PXDzvJ3OVs37RLdfOuPrlmy1/VGdJV/vz4VWkMoNhQZeszbPmbU9/+B8WoWjPVh4kHYn 3Y/8Z+6UcqaMyiboLzrQQqEb196emIDnVO8TF60jSVgzyFuaDl6UVawTse2KxFscIHC5 c6c860Wq+qvl3fKJ/8wD4w8AvGoA8G4C06IZRk74B3di86AIqv9RU4ZE2APXVWZl2chh crwn2QEOZUWXjA4p9ee4n19LlqsDEWRAHq33cqopc6nbpk+tDqx8LO0WQLauCZ2/hxbX fB1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715070406; x=1715675206; 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=4ABsOP8SEu68sVFLiASZm/u0Hmy8w+mAVpH8nCUwY0A=; b=GlsKaftK6ZJaijXUePoB1ypPGqlOD91dcud8wnrBAJtXnUzhbBZ2hgAfRZeskmqE5f lwLJqgGd8Jp029TqTEhGKoxjg8y+0NjWqRb4QMCxgXe/6P/RPZrB72u1TnD4v+cC3k9V 0UgHp6Ri/SthvBZzSlO+RVSrVJUXUHEAtaLYaRywLS1Ji496rKC0LQrFa7BiVICej32i ByCFSL8B3r6WNBQsFzAahWsL13KFONhKMTzRiuYux/QsHz0OyPmL4mG6YqBm/Jpzr2Ro JcE6pA7gmU8i/HON0q6LF7Kfxoag18e4ddwSGmAvNVwn5IEptN15np9FDES49ydtLAJK LWLA== X-Forwarded-Encrypted: i=1; AJvYcCXeL9MgHd20Sv3RzRXNF0gdC7eCZgy4ABcTpb+3OBub7lHt6juCFJrv7wAGRosvhiRYDQMiC6amW/Jh9bLuCWQpJlY= X-Gm-Message-State: AOJu0Yxa73yT8pmFnGEzrPZUeyHsJ1TPOIEbyX4JHPKAqaDElWi/o5io vjxxgskY2mn3JTj8sIdYc2CKiKs8VqoVZ04H4ly7t/Lb6Kau/2KRXkqE5L5VpSt4ZXPalZwJZYb APF+iS11c24XhinrQIFdAAqe4S+s= X-Google-Smtp-Source: AGHT+IF0jDUUvlcUjVjTQnZ6YPtFqBDAtPQ4FSE7s7+H1V9lbJUvo7JZ6dtpIaCxEfRyi6RpoG4WFbQ41B0qq/63bk8= X-Received: by 2002:a50:8755:0:b0:572:a183:49a4 with SMTP id 21-20020a508755000000b00572a18349a4mr8345591edv.28.1715070405633; Tue, 07 May 2024 01:26:45 -0700 (PDT) MIME-Version: 1.0 References: <20240501042700.83974-1-ioworker0@gmail.com> <20240501042700.83974-4-ioworker0@gmail.com> In-Reply-To: From: Lance Yang Date: Tue, 7 May 2024 16:26:34 +0800 Message-ID: Subject: Re: [PATCH v4 3/3] mm/vmscan: avoid split lazyfree THP during shrink_folio_list() To: Baolin Wang Cc: akpm@linux-foundation.org, willy@infradead.org, sj@kernel.org, maskray@google.com, ziy@nvidia.com, ryan.roberts@arm.com, david@redhat.com, 21cnbao@gmail.com, mhocko@suse.com, fengwei.yin@intel.com, zokeefe@google.com, shy828301@gmail.com, xiehuan09@gmail.com, libang.li@antgroup.com, wangkefeng.wang@huawei.com, songmuchun@bytedance.com, peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 89F37A0005 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 8wba9aquxg9mx37dbds9e9d7hg7jic9r X-HE-Tag: 1715070407-286651 X-HE-Meta: U2FsdGVkX1+qB2G0vkL2DEvBrMa8G1dqhYzWDvl9gfL3xE6b2mK9i2YVdz9LBTWUYqObKxDyKE1CRvJhNupvHUFS6Jh3ys4fODZVtifilA+RLMhVpHVPu2M9Y9paT7ux5CubD86XlaFhxxd9JvkQZprhtDTUDylbClZ706RcHuexasNiPw1fxs54zbAK5jpFP/+89qe7TnftPzzeLilzJFbEBqfLiWX0i/FzDcpwHckm7TjwW/LAkCI13S9Mp+Z7QNuLFO11+Ck/tDQWioHZWief3xIPNpDJAsMHzsm/5oK+/q5/N+664cBbpcYTH2wPsbY+uftTv/K4KzbM3eZLT9RmgmWegb+csJeAoGEnXsYsJWgNl+RgqHHzJ902prpwwDPp+wCpjNlFS0Mwtrwrr/lBLy5nQl9A1Zxy+tSTRfV6iARnwmzWQlv7QPH/t9qz6UIuOjZoc+hzCeKoUr3mqPJ8v+n+2PSa5Owap/5E+9ODHLEddNfSCUfsUHQU2pPmml99mX42jKMG7006vAXy390py8AL9pC2qq5tELqYRIDAfvsw2jCscsVHSaA8OupjaIJQs1d2QVSxVMJSDRCDFHGAMhp3xDflzvbMNapKaPULeqD7lqW2wdD+Ykb+V1zdHRm82ooNx6UdegVqoJgV8t1c66GZkQvdvHfLPK8SNqAVgf/iTO37MXAyKA5eUVM+Fz/gTviVzg/E+6Pr3rYOKMxZUaolfH5aPZg2ZDHoPHz8eCnvoH2fAsZ2+8HXkZV9tpCGd0ahcT0RlRYsdpBYdESIog45yogMExc/xZnzENScal0hjxxkwRbERCOs3lF0gyttdvwmLxDxPOQj+NdGnBSbawvolqHN2vwHHsFJyULcYUtvp1fJp5S96QZGZBmNXCopT3H9RIlFvsOv1c0dAF18pKpHcgOGXZGpvP6Qo+PgKo1TX6qwZHDKMnlLiaytXF8IQgKy464OdqltagM dNLPI67A EVP79tGhPm99osOER2X5ZVZGTVLnc1rVY2NSaoRfS9ZQhk1UBga0Msw0XjwknpVpFvSbOdTDbo9hipYf/vWcehUYbwDO+03WFNWLxon/OTwXSxgZpkPUB5cfiGEb3/cMGpVrxAgf9i2cUwNwsMMgbsyGnrRMceMRNrBgHv0TbpOjjHU1Oj91EuGNLg/hCrbK2hKwxPCA6dwgUF+K+l0evPTpw3Spu4oGV+1IMWuLO3F4q7ZU28MFDBComurCoBzQ3SnsL1uCU7l3jrNd6sUR6H3NEuuo2Hq3na+PP5XjRBjw36gNcr1hx3XxVDn3VeueBNSU5q7cSC2Fo6U6hdl+ell11L7JWnCSA0r0AUVf84ueHYkZJVIfsmC83BCqlCtYCBvKCcr8yWdwosQvFDMBTlhbSXeOeEpHa09MRQVEajFSpaGGRNJxlT/ZkSuGggjI1nzee3S/ZT7g0c3qu8PiDMvS+/efJOII+hWynAae6i5YJNt+Hdw3jStShpw== 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 Tue, May 7, 2024 at 2:32=E2=80=AFPM Lance Yang wro= te: > > Hey Baolin, > > Thanks a lot for taking time to review! > > On Tue, May 7, 2024 at 12:01=E2=80=AFPM Baolin Wang > wrote: > > > > > > > > On 2024/5/1 12:27, Lance Yang wrote: > > > When the user no longer requires the pages, they would use > > > madvise(MADV_FREE) to mark the pages as lazy free. Subsequently, they > > > typically would not re-write to that memory again. > > > > > > During memory reclaim, if we detect that the large folio and its PMD = are > > > both still marked as clean and there are no unexpected references > > > (such as GUP), so we can just discard the memory lazily, improving th= e > > > efficiency of memory reclamation in this case. On an Intel i5 CPU, r= eclaiming 1GiB of lazyfree THPs using > > > mem_cgroup_force_empty() results in the following runtimes in seconds > > > (shorter is better): > > > > > > -------------------------------------------- > > > | Old | New | Change | > > > -------------------------------------------- > > > | 0.683426 | 0.049197 | -92.80% | > > > -------------------------------------------- > > > > > > Suggested-by: Zi Yan > > > Suggested-by: David Hildenbrand > > > Signed-off-by: Lance Yang > > > --- > > > include/linux/huge_mm.h | 9 +++++ > > > mm/huge_memory.c | 73 ++++++++++++++++++++++++++++++++++++++= +++ > > > mm/rmap.c | 3 ++ > > > 3 files changed, 85 insertions(+) > > > > > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > > > index 38c4b5537715..017cee864080 100644 > > > --- a/include/linux/huge_mm.h > > > +++ b/include/linux/huge_mm.h > > > @@ -411,6 +411,8 @@ static inline bool thp_migration_supported(void) > > > > > > void split_huge_pmd_locked(struct vm_area_struct *vma, unsigned lon= g address, > > > pmd_t *pmd, bool freeze, struct folio *folio= ); > > > +bool unmap_huge_pmd_locked(struct vm_area_struct *vma, unsigned long= addr, > > > + pmd_t *pmdp, struct folio *folio); > > > > > > static inline void align_huge_pmd_range(struct vm_area_struct *vma, > > > unsigned long *start, > > > @@ -492,6 +494,13 @@ static inline void align_huge_pmd_range(struct v= m_area_struct *vma, > > > unsigned long *start, > > > unsigned long *end) {} > > > > > > +static inline bool unmap_huge_pmd_locked(struct vm_area_struct *vma, > > > + unsigned long addr, pmd_t *pmd= p, > > > + struct folio *folio) > > > +{ > > > + return false; > > > +} > > > + > > > #define split_huge_pud(__vma, __pmd, __address) \ > > > do { } while (0) > > > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > > index 145505a1dd05..90fdef847a88 100644 > > > --- a/mm/huge_memory.c > > > +++ b/mm/huge_memory.c > > > @@ -2690,6 +2690,79 @@ static void unmap_folio(struct folio *folio) > > > try_to_unmap_flush(); > > > } > > > > > > +static bool __discard_trans_pmd_locked(struct vm_area_struct *vma, > > > + unsigned long addr, pmd_t *pmdp, > > > + struct folio *folio) > > > +{ > > > + struct mm_struct *mm =3D vma->vm_mm; > > > + int ref_count, map_count; > > > + pmd_t orig_pmd =3D *pmdp; > > > + struct mmu_gather tlb; > > > + struct page *page; > > > + > > > + if (pmd_dirty(orig_pmd) || folio_test_dirty(folio)) > > > + return false; > > > + if (unlikely(!pmd_present(orig_pmd) || !pmd_trans_huge(orig_pmd= ))) > > > + return false; > > > + > > > + page =3D pmd_page(orig_pmd); > > > + if (unlikely(page_folio(page) !=3D folio)) > > > + return false; > > > + > > > + tlb_gather_mmu(&tlb, mm); > > > + orig_pmd =3D pmdp_huge_get_and_clear(mm, addr, pmdp); > > > + tlb_remove_pmd_tlb_entry(&tlb, pmdp, addr); > > > + > > > + /* > > > + * Syncing against concurrent GUP-fast: > > > + * - clear PMD; barrier; read refcount > > > + * - inc refcount; barrier; read PMD > > > + */ > > > + smp_mb(); > > > + > > > + ref_count =3D folio_ref_count(folio); > > > + map_count =3D folio_mapcount(folio); > > > + > > > + /* > > > + * Order reads for folio refcount and dirty flag > > > + * (see comments in __remove_mapping()). > > > + */ > > > + smp_rmb(); > > > + > > > + /* > > > + * If the PMD or folio is redirtied at this point, or if there = are > > > + * unexpected references, we will give up to discard this folio > > > + * and remap it. > > > + * > > > + * The only folio refs must be one from isolation plus the rmap= (s). > > > + */ > > > + if (ref_count !=3D map_count + 1 || folio_test_dirty(folio) || > > > + pmd_dirty(orig_pmd)) { > > > + set_pmd_at(mm, addr, pmdp, orig_pmd); > > > + return false; > > > + } > > > + > > > + folio_remove_rmap_pmd(folio, page, vma); > > > + zap_deposited_table(mm, pmdp); > > > + add_mm_counter(mm, MM_ANONPAGES, -HPAGE_PMD_NR); > > > + folio_put(folio); > > > > IIUC, you missed handling mlock vma, see mlock_drain_local() in > > try_to_unmap_one(). > > Good spot! > > I suddenly realized that I overlooked another thing: If we detect that a > PMD-mapped THP is within the range of the VM_LOCKED VMA, we > should check whether the TTU_IGNORE_MLOCK flag is set in > try_to_unmap_one(). If the flag is set, we will remove the PMD mapping > from the folio. Otherwise, the folio should be mlocked, which avoids > splitting the folio and then mlocking each page again. My previous response above is flawed - sorry :( If we detect that a PMD-mapped THP is within the range of the VM_LOCKED VMA. 1) If the TTU_IGNORE_MLOCK flag is set, we will try to remove the PMD mapping from the folio, as this series has done. 2) If the flag is not set, the large folio should be mlocked to prevent it from being picked during memory reclaim? Currently, we just leave it as is and do not to mlock it, IIUC. What do you think? Thanks, Lance > > What do you think? > > > > > > + > > > + return true; > > > +} > > > + > > > +bool unmap_huge_pmd_locked(struct vm_area_struct *vma, unsigned long= addr, > > > + pmd_t *pmdp, struct folio *folio) > > > +{ > > > + VM_WARN_ON_FOLIO(!folio_test_pmd_mappable(folio), folio); > > > + VM_WARN_ON_FOLIO(!folio_test_locked(folio), folio); > > > + VM_WARN_ON_ONCE(!IS_ALIGNED(addr, HPAGE_PMD_SIZE)); > > > + > > > + if (folio_test_anon(folio) && !folio_test_swapbacked(folio)) > > > + return __discard_trans_pmd_locked(vma, addr, pmdp, foli= o); > > > > Why add a new function, which is only used by unmap_huge_pmd_locked()? > > Seems can be folded in unmap_huge_pmd_locked(), but not a strong > > preference:) > > Thanks for the suggestion! > > Personally, I prefer adding a new function, rather than folding > __discard_trans_pmd_locked() into unmap_huge_pmd_locked(). > > While unmap_huge_pmd_locked() currently only deals with lazyfree THP, > It could be expanded to support other types of large folios that are > PMD-mapped in the future if needed. > > Thanks a lot again for the review! > Lance > > > > > > + > > > + return false; > > > +} > > > + > > > static void remap_page(struct folio *folio, unsigned long nr) > > > { > > > int i =3D 0; > > > diff --git a/mm/rmap.c b/mm/rmap.c > > > index 432601154583..1d3d30cb752c 100644 > > > --- a/mm/rmap.c > > > +++ b/mm/rmap.c > > > @@ -1675,6 +1675,9 @@ static bool try_to_unmap_one(struct folio *foli= o, struct vm_area_struct *vma, > > > } > > > > > > if (!pvmw.pte && (flags & TTU_SPLIT_HUGE_PMD)) { > > > + if (unmap_huge_pmd_locked(vma, range.start, pvm= w.pmd, > > > + folio)) > > > + goto walk_done; > > > /* > > > * We temporarily have to drop the PTL and star= t once > > > * again from that now-PTE-mapped page table.