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 53E1CC25B5C for ; Tue, 7 May 2024 06:32:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 826816B007B; Tue, 7 May 2024 02:32:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7AF5A6B0082; Tue, 7 May 2024 02:32:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64F936B0083; Tue, 7 May 2024 02:32:20 -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 42F526B007B for ; Tue, 7 May 2024 02:32:20 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4A3C940CB4 for ; Tue, 7 May 2024 06:32:19 +0000 (UTC) X-FDA: 82090630398.29.06A8AEC Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf26.hostedemail.com (Postfix) with ESMTP id 53EBF14000B for ; Tue, 7 May 2024 06:32:17 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GKSnVQWn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=ioworker0@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715063537; 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=DACqjnDAG0H4TrSShlBsGd57EdUYG6Ww5S2vGo61t14=; b=QP+mCh/z45wI78e8vydjl/Up4dFHcscAeAvAo+FG5wkKApbi8tY86lCbqEH374jDRirEx4 UDVPSYPRewr1QesKWMa1HIQ1vj2+raEy8e36bAp8Ea7f4nCFkNumoEZpyGfw+h0a5Bjktt QdthiN5v096XaaR3vdeO0v0wd++GrL0= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GKSnVQWn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=ioworker0@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715063537; a=rsa-sha256; cv=none; b=PJ7lK6dvDN4BMlx1R/2jEscIhOoNrWwNyhnpzalZUIpzYjq9+mQpvs3GnTNzPUqsmWnnip 07S3Z7pwnBiWHsbPhME/P2E/6A+9QIO1rpkPHrlXtd2yN1U7wOlvkqdLrIHJjpD/sTHPBv P8X8OBUdMLPmiS546kWbv7qHnT3ijYY= Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a59b49162aeso549938266b.3 for ; Mon, 06 May 2024 23:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715063535; x=1715668335; 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=DACqjnDAG0H4TrSShlBsGd57EdUYG6Ww5S2vGo61t14=; b=GKSnVQWnecvNsHmmaawIVuPigq2pZMKvJD2zAI75iJPb8cb67gRwXPhNowxFWC9W5H bgYcdk1+DQUDAMgIu+FA2DLzYGBUMEGtjH3c93NJqJzv5r68b/XtV8LqkLQMfgDQj9eD fI+6Ev5sfQ1LHZseT7lfgteGm/EEmD4JZeDqhfss2iVvb9nf899OYNJXZF3zGs/TfEoh WyBvIvC3/lNI+ziS47rSfFkYhHr0OSKJ5UW3nCRVJLMR9lGSJtwrp0jodC1G6B5PrFNU HXZQ3kNfvCXBtnv5Aw7q7MbBWKGQrywHG4ZIDWP8oYl0nPEKIZwqAofEO6/fHqb6CA6L hbnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715063535; x=1715668335; 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=DACqjnDAG0H4TrSShlBsGd57EdUYG6Ww5S2vGo61t14=; b=bV8RF3wakbA/l/NCvm2C3Mlo7Kbp9Nnm2BUtIC7SmYdeN4ANGiFq2dBTLSq/6qmaKa aEzXhHfjtLbDw8Pgm3TMsCt3ppEnttUlWxYIasTxCECxYRVXBf1tswrjjMCLmheXn8XF xly4CaKkV+dVNI+alPWHesFgxrbkycNIDWmEhiDwICKVas4xysTZEyphX6dWNgm2yWU5 5aCK9FlDhCNIGzWpfeSlBm0Z6dBswJV3aC/I3IN8up7LVS98igrFXaMmsVhXY4cihwrT +LSnpLTCjvI5WCYpcGJ0tPAJDQVAii9TKXxc78xipfCQhhbhbwmjx60NwYZHrmVvkeld 5X4A== X-Forwarded-Encrypted: i=1; AJvYcCU+OUQu5uqNRHbH42hgx+jehVhlX1bhz1BdP7J5iUFZ/ygRo7z60qjCrxlu3nmZfJU7LEwTen0Pqtdc9LDu5bRn+Xs= X-Gm-Message-State: AOJu0Yyk2ED6HoJEkol0+3oGGhmObCHfBsy3vCiLDcUQhKmqs4BWilCz GVPtiZGgYq8itziH8fI7AGYh1AncTXskItqMLmY5HZvNZzT2hs/YUrDD8k1lCNiSpTQZNEiOv9C CnwRLQiHDaacv1nbBcFUu3Qk3hVs= X-Google-Smtp-Source: AGHT+IFxAwgX9ujafnqE6uur+NrXr1K7AHYM1IkHzuHZM6Y05H84S5oN5lk/83BVQUJbnhxBUJ/julxzNQhkkxzq2Qw= X-Received: by 2002:a05:6402:354d:b0:572:6ee9:5a2d with SMTP id f13-20020a056402354d00b005726ee95a2dmr8396819edd.12.1715063535205; Mon, 06 May 2024 23:32:15 -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 14:32:03 +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-Server: rspam07 X-Rspamd-Queue-Id: 53EBF14000B X-Stat-Signature: 5e61cg95df6psoxperm3mudzmf81psyt X-Rspam-User: X-HE-Tag: 1715063537-940976 X-HE-Meta: U2FsdGVkX19EXSCicBf9Lg0wPjj9RDwdFD30612bS0hxt7Ew6uYO2mXcjYi5mrox2ZESgxPrE5JibdQQ6JSm0BTQhFTuyhw0kQ/WRernWVpnKT3ch7n9qHbLRGphdUlqwpxcPNbOhVK3BEZODo/6ryStJkG5wvvAECyagQWICQ/CPDgLC4OE6+QsQ3TNihhyQKCfHKoR6eeKJUTIP1Y9Qct+7sttdGWTqcNFvwlizLr1ClafZ/ykrbONX5zM4xWSQLTQsPtDabmNEwp7JHDj/MuV+7GrznaAC+2AvLhzaOS22WgIDN6+gPSw9B/s2GSpwffHkA+mpMJRAMkV7k8c+4wdP1ei3FYpyc2k8qKlU/CqmDMfYvql1nT8WAb2xwkp0eCyC+yk1xOAJTR5NlAv2c5ub7yq/uSWDk5yT/UjlaTxxvUhiRMYiJSRr90tGKbRH34hMRa/+JN2h+JRqfQQVs7BR4WoWnmOhB+45TwE0xvP66RK+4WGiz3vTuhB2Trsop8loTlSb53iK9syFLI/UBNpwW7ZPAaE/n+JKe0yHYB19zVArTbZBPHDPVyS1oKnI44O4eJNgrMnofq8ax/+NXCh1V0v9YvcnGBDVpUjZ9s6upSM+3h3Kf9wGPKltGZ3l/XTvxqMPfcPUHhXG6SrGT3n6gUw7bDGj5xaXKyH9OHqkS18tKeXu2Mhqe5eEDgV35o0WeN/gj/ejPnOHTij3FkIcvhex53xVgGyYhTByWCUqYyKh4UyPydzDxltUx8S7Xb6tyjY9RMrnvCyUVRV5prALz1KbUHxEiPHq4fGGvL0n2t7AtTfO2UtDdY7rhLYqnl7MR47cTNTKZERuBZMtOYY6IC6vdG90xEmscrh+CNlPkctNo7z0TvAWok/JN3oSuBRZuIM0LA/AZ3kzazrZFUEhD6iSgvftHGU1fwL3TXMs+BvHZlQRWDLzC8ExkRlS/bKO58ybr5SZwbhKKW +RCXHzB6 N8EJHgMke4Mnt/Hym9XWXjA8PQBL7urnZyTBjA3TsHY/tAXorWSEqrXffQnD878VTYfsD+W2VHNWtUok8wqxmIJYB1+iBR/fQ/7NLIQ3ZLePrTay2q8AFivWC9fS9BNvBVgFCUqHPhtzHziLfvvirgw2x3NzW0VOBB+GsOcT/pqp6AbaOh2jY06nx6MQMl/7FnEq5Uhv89CQ01RCwUTe/KT7ia4EmQwXcnTyfHRM7haPtWulOPGP42Db4R++jSvzv0sfqNx0YlYm9WCvwE5q4pimuFC1aXyKCmh0hZWYPiYQTRQqwjDlckbZYT/hcK9MYwX/w9GoatatH76hleDjRbxO8R3fO2TUfLbTw4n4vvTAHO+rD5+uVZIqOglRng0LmxiqJgKBONZSPqqdgF7qI8lZtqYFU2DJ03BUV3R2kUyn9pQ1woQLLXBKK7gUZB4Nage5jx0ozi9s/E2HoDiHE1B7WqifzP13xY0QiYZhqrxilfrr+tcV8ELK3lA== 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: 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 ar= e > > both still marked as clean and there are no unexpected references > > (such as GUP), so we can just discard the memory lazily, improving the > > efficiency of memory reclamation in this case. On an Intel i5 CPU, rec= laiming 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 long = address, > > pmd_t *pmd, bool freeze, struct folio *folio); > > +bool unmap_huge_pmd_locked(struct vm_area_struct *vma, unsigned long a= ddr, > > + 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 vm_= 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 *pmdp, > > + 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 ar= e > > + * 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. What do you think? > > > + > > + return true; > > +} > > + > > +bool unmap_huge_pmd_locked(struct vm_area_struct *vma, unsigned long a= ddr, > > + 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, folio)= ; > > 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 *folio,= struct vm_area_struct *vma, > > } > > > > if (!pvmw.pte && (flags & TTU_SPLIT_HUGE_PMD)) { > > + if (unmap_huge_pmd_locked(vma, range.start, pvmw.= pmd, > > + folio)) > > + goto walk_done; > > /* > > * We temporarily have to drop the PTL and start = once > > * again from that now-PTE-mapped page table.