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 CF18CC5B543 for ; Tue, 10 Jun 2025 08:37:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C8666B008A; Tue, 10 Jun 2025 04:37:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A0216B008C; Tue, 10 Jun 2025 04:37:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48EC96B0092; Tue, 10 Jun 2025 04:37:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 27B166B008A for ; Tue, 10 Jun 2025 04:37:19 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C668BBF0D8 for ; Tue, 10 Jun 2025 08:37:18 +0000 (UTC) X-FDA: 83538836556.15.1BC6F14 Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) by imf28.hostedemail.com (Postfix) with ESMTP id EDE56C0005 for ; Tue, 10 Jun 2025 08:37:16 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fmOWjImB; spf=pass (imf28.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.47 as permitted sender) smtp.mailfrom=21cnbao@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=1749544637; 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=nnar+GeWh3IDeNTEo/pLO1+fWay4pzszrojH85IBaoA=; b=16Pp36PLf/j3qLbrfaG7Ta5F9uUQ/wfR4Qk4y4IaEOZIn/VlB+BPUwcFLCSNiASa260sqn fmqo71i/YDkpAKSBGiYoidpcxFqjDG2SDEO9rQb/CFaY2LLi3Yz09Map+c7B62xM9zbWms DZ30OBwhM6E7jElqgZV2ErDQAjPTwwg= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fmOWjImB; spf=pass (imf28.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749544637; a=rsa-sha256; cv=none; b=8RP0odrxsq+PBFcMW9ldIZhWHB8Y2b+7hliemuVGkXVZv7CXSuZWMVVMm6lrCp0DkP0psg zDSBIAap14ldLZFvD0S5v/10w8kfoxCHkgg7c5cbkf1kpoGmgNNzls+6pDgv2edNg+7QdA pFAyluUbVl12geMYcN/CNMBjZQILUAI= Received: by mail-vs1-f47.google.com with SMTP id ada2fe7eead31-4c6cf5e4cd5so3742208137.2 for ; Tue, 10 Jun 2025 01:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749544636; x=1750149436; 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=nnar+GeWh3IDeNTEo/pLO1+fWay4pzszrojH85IBaoA=; b=fmOWjImB3/01tXRfCowOHk4Bf5UZCbBjjMog48jxGrGX0ORT0uZJ9px9BMNQ68gPoA Vc3FI6kt0cKEbYNVpLWTzvRoojObM14a8sM/wicqTPTCte20/EDr8jJUuS1OdVqM2zpn +qEkflUXl+dyQtx9dYl4y3nNGuLVrh2wISelnoRB0x0TMfrPyz9g2j49z0Sw2NpZ/OT2 yLC0vZ8+hp1a9PKvWzi4cpeWFist9oXpm3eL+AEpFm3eAf98sHZA4cnzP+nKiRnxKVeG LjDOJjrPyxBPt1QEJscF5s1umshYruOyvDg8quK1Wic5BkFh0ZQc1fg+sVi0LxGW3L7u RpQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749544636; x=1750149436; 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=nnar+GeWh3IDeNTEo/pLO1+fWay4pzszrojH85IBaoA=; b=d36IvYVCM8y73yyyjRUaYC9k9YiZ1FsCb6m0JN4JlelJ4ndThpgZ6qlsa2B8C3lNxg 8wQJSURCuBmdDcg2hGnTTvGY1Q+5c0h6mWMXZWkA1RrzE+wLxVQjTL5Irdst3EbCNKix VlNMf4qjSeoDhjPj3I3HY5SDXEtDAONx4agecs1ig4s/bxAdE0VYA8KPHlgW/0kEHRqh T5oXVBqnToIyIGqIzmvElgkA4lF1+4La2V9F9+AzwIeC693RCnsd/vHXzZmPf8tCmFpR Amul5FDTBPhFCqOGGdvk57LnXSScsJ6zZrXBKe9BPKFmCicxw/sgW+bKMMUYmO+If6JT QSPQ== X-Forwarded-Encrypted: i=1; AJvYcCV099xax3DGnPH0zSzchInaf71gm2IZa9PW5HEJ7Sby9kUaGnNq/o6oDtlXdJNRENjdmhp9//4LKA==@kvack.org X-Gm-Message-State: AOJu0Yy1vuQBKXfksBrP2KRYIbnvb8WJI5YsN84fgRPkaHH1rWfz40+B JXmaoHnlbCQsSnHYr2obxirrH/09aFOGLnnWcLTMMTf6Tph4UC7AGr5JFcTjnYDclt/imuxmsv9 zLPaY/7UalQUovq1hBwFR4YGiBbekxSvfQg== X-Gm-Gg: ASbGncupjr+LkErDe5vnyBB+u8J8YX3nkgiqyCu+XzfAbNhO6WN22EDg2ygL5XFIJYH qkBSneOx/T0UjJe2pjaq7DPmCdZ7mhRa74q5j5a3L8n0UWXLZfkv7eccVsfsAhzJBMajXuHa9/u Pm3iFSPNTNdwQOjvp/zbxXip5Vxbm7QYA92yVBTPa09oWc X-Google-Smtp-Source: AGHT+IHAuCzPail3KyWEnUuOTHkl0YO3F1D2VwSe8uGoUSEXuglFPFY6oRR0/8GCZZvsxs5d/hq5WZkunJGfAfg9F3o= X-Received: by 2002:a05:6102:3ca4:b0:4db:e01:f2db with SMTP id ada2fe7eead31-4e7a8041a72mr1174771137.0.1749544635885; Tue, 10 Jun 2025 01:37:15 -0700 (PDT) MIME-Version: 1.0 References: <20250610035043.75448-1-dev.jain@arm.com> <20250610035043.75448-3-dev.jain@arm.com> In-Reply-To: <20250610035043.75448-3-dev.jain@arm.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 10 Jun 2025 20:37:04 +1200 X-Gm-Features: AX0GCFvNQf_tJMRGWeweQukrOmZB5LYVa1rypl060qryW1t_FAIfNamJEbB--IY Message-ID: Subject: Re: [PATCH v4 2/2] mm: Optimize mremap() by PTE batching To: Dev Jain Cc: akpm@linux-foundation.org, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, vbabka@suse.cz, jannh@google.com, pfalcato@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, david@redhat.com, peterx@redhat.com, ryan.roberts@arm.com, mingo@kernel.org, libang.li@antgroup.com, maobibo@loongson.cn, zhengqi.arch@bytedance.com, anshuman.khandual@arm.com, willy@infradead.org, ioworker0@gmail.com, yang@os.amperecomputing.com, baolin.wang@linux.alibaba.com, ziy@nvidia.com, hughd@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: EDE56C0005 X-Stat-Signature: te33gio55gckbtnret1utypfhsib4p57 X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1749544636-242531 X-HE-Meta: U2FsdGVkX190UlfgLxNjWyPzWi2zu0A1d7NQoRKToW+UQ/PZp+7fxwQ3NM0dCLesng7aNpXO8SLrAUYIPVdIvqj4Jv04w1f++ZtP0pwbYVNuzREc5zMJuQxnTF+sElWkOO/fp+QjfyuV170PLpL5/OiymGFuUCIExVMJyFrtQ5qvyWq3O+6ya/SwioKwLCRWBHU6dBYnpkBeKfojb/RAIgEk2yR5mR47BdnXzREzJyhHuExKR+BFecrcAaXz2w64VBK2mFxhwYDRg4oUu/AZAkGaz3CipCv+3XsIihJ+vXkqr9uhbOAr7OUM9i7N1IadVTxK0G8dlmAWLLDpo+Z6Y2eOGQDJTcxm9QOb8d9kmHT7Lii6or7MUA0FSI6ru96MNeuQQ1Z10UBr5YGuVIgQSRr3e27/u2K9x2ffe8UwHJTm89Q64rWWp4Xb0jXY/U5obyx9iBXQDRS0q94E/PU3+ygH4A0rgoemNbaftRrVkOnaji6ISUjM4E4Fp5ZG1DUDHkJ/9QlisEuWlhsZP12Wf1G3HAhT9nzS0YF+wSTKjzVBsQQt23HpTkKP/hxpWsfvRhMyBNxaqp+uM8Ms0LFRHrJYm5ZKFINvyLmiycy2rEipRzIe7Sg0XZNgR29+xBFGrs8EJ/NELMjCj1AnVIUnekZ+kdXwwkcrHdd+aZ1wg5G1T/Y8PE/L7U7UuDDwvkH16ZXTjHlrwV83VTi2SUrpbt+CWrwxDHlRfFVEZKz/vCxxC1fFIKpBhz7eHTbPzeV9k1Vq335zWnyjMLB86S/862GfC7w6DpiQquYrqK+Tdm4YEpDOVwnDelLd6p1ymRWDQ23Gz9mGSfFCNDkTMT9y1dHw8twuNLcVaWZkR36tJNQOJG37V+9y15qzwxFRTysaY6vVNEbVC+pM6zHNIh7mWZKI1YMdLHOyqyYwQOncKmm25uzZu+xScO+MnjC0WqRS8uosHPUZuQ2JzEB4sOW nYnf8m/n OzJ6ZpCkqZZcsivk9wj9ZG6fIMoF9lngnnvdheIluNazhvbtGV5WCZ90Ke/0LiZuNthEZjk/L253TvtNSeN0YLy2tSdg8RHFwNayXPTjdfR2wK1VrkEFC0X1ZePGGrMnRoiI5vAbne4sEVFRRQZ/CvMi+/V8UnHeEz66hg5D4bV4auJMAki4EEoYUAWZ2/umhw12XdFg3gccn9oTRLIegpFXNGfdV9Cuhf+QT8E1c3u0woVF8B2n4WIWoQQhhGFBrvdaDxgV82VYrN6XpwJKRyhBIR7SVlARUyboek2YSEGvSSj5LJZMlt/VzRAJfHbdaG7VbDJLsXCakIjuBIqJVCmzC/RhrMvFjxCPi23cKQRrGnEdhy7dDkpgYYP2XaSjXRd6Z3GunmQJIciSS0iVRMxKG8A== 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, Jun 10, 2025 at 3:51=E2=80=AFPM Dev Jain wrote: > > Use folio_pte_batch() to optimize move_ptes(). On arm64, if the ptes > are painted with the contig bit, then ptep_get() will iterate through all= 16 > entries to collect a/d bits. Hence this optimization will result in a 16x > reduction in the number of ptep_get() calls. Next, ptep_get_and_clear() > will eventually call contpte_try_unfold() on every contig block, thus > flushing the TLB for the complete large folio range. Instead, use > get_and_clear_full_ptes() so as to elide TLBIs on each contig block, and = only > do them on the starting and ending contig block. > > For split folios, there will be no pte batching; nr_ptes will be 1. For > pagetable splitting, the ptes will still point to the same large folio; > for arm64, this results in the optimization described above, and for othe= r > arches (including the general case), a minor improvement is expected due = to > a reduction in the number of function calls. > > Signed-off-by: Dev Jain The code appears correct to me: Reviewed-by: Barry Song > --- > mm/mremap.c | 39 ++++++++++++++++++++++++++++++++------- > 1 file changed, 32 insertions(+), 7 deletions(-) > > diff --git a/mm/mremap.c b/mm/mremap.c > index 180b12225368..18b215521ada 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -170,6 +170,23 @@ static pte_t move_soft_dirty_pte(pte_t pte) > return pte; > } > > +static int mremap_folio_pte_batch(struct vm_area_struct *vma, unsigned l= ong addr, > + pte_t *ptep, pte_t pte, int max_nr) > +{ > + const fpb_t flags =3D FPB_IGNORE_DIRTY | FPB_IGNORE_SOFT_DIRTY; > + struct folio *folio; > + > + if (max_nr =3D=3D 1) > + return 1; > + > + folio =3D vm_normal_folio(vma, addr, pte); > + if (!folio || !folio_test_large(folio)) > + return 1; > + > + return folio_pte_batch(folio, addr, ptep, pte, max_nr, flags, NUL= L, > + NULL, NULL); > +} > + > static int move_ptes(struct pagetable_move_control *pmc, > unsigned long extent, pmd_t *old_pmd, pmd_t *new_pmd) > { > @@ -177,7 +194,7 @@ static int move_ptes(struct pagetable_move_control *p= mc, > bool need_clear_uffd_wp =3D vma_has_uffd_without_event_remap(vma)= ; > struct mm_struct *mm =3D vma->vm_mm; > pte_t *old_ptep, *new_ptep; > - pte_t pte; > + pte_t old_pte, pte; > pmd_t dummy_pmdval; > spinlock_t *old_ptl, *new_ptl; > bool force_flush =3D false; > @@ -185,6 +202,8 @@ static int move_ptes(struct pagetable_move_control *p= mc, > unsigned long new_addr =3D pmc->new_addr; > unsigned long old_end =3D old_addr + extent; > unsigned long len =3D old_end - old_addr; > + int max_nr_ptes; > + int nr_ptes; > int err =3D 0; > > /* > @@ -236,14 +255,16 @@ static int move_ptes(struct pagetable_move_control = *pmc, > flush_tlb_batched_pending(vma->vm_mm); > arch_enter_lazy_mmu_mode(); > > - for (; old_addr < old_end; old_ptep++, old_addr +=3D PAGE_SIZE, > - new_ptep++, new_addr +=3D PAGE_SIZE) { > + for (; old_addr < old_end; old_ptep +=3D nr_ptes, old_addr +=3D n= r_ptes * PAGE_SIZE, > + new_ptep +=3D nr_ptes, new_addr +=3D nr_ptes * PAGE_SIZE)= { > VM_WARN_ON_ONCE(!pte_none(*new_ptep)); > > - if (pte_none(ptep_get(old_ptep))) > + nr_ptes =3D 1; > + max_nr_ptes =3D (old_end - old_addr) >> PAGE_SHIFT; > + old_pte =3D ptep_get(old_ptep); > + if (pte_none(old_pte)) > continue; > > - pte =3D ptep_get_and_clear(mm, old_addr, old_ptep); > /* > * If we are remapping a valid PTE, make sure > * to flush TLB before we drop the PTL for the > @@ -255,8 +276,12 @@ static int move_ptes(struct pagetable_move_control *= pmc, > * the TLB entry for the old mapping has been > * flushed. > */ > - if (pte_present(pte)) > + if (pte_present(old_pte)) { > + nr_ptes =3D mremap_folio_pte_batch(vma, old_addr,= old_ptep, > + old_pte, max_nr_= ptes); > force_flush =3D true; > + } > + pte =3D get_and_clear_full_ptes(mm, old_addr, old_ptep, n= r_ptes, 0); > pte =3D move_pte(pte, old_addr, new_addr); > pte =3D move_soft_dirty_pte(pte); > > @@ -269,7 +294,7 @@ static int move_ptes(struct pagetable_move_control *p= mc, > else if (is_swap_pte(pte)) > pte =3D pte_swp_clear_uffd_wp(pte= ); > } > - set_pte_at(mm, new_addr, new_ptep, pte); > + set_ptes(mm, new_addr, new_ptep, pte, nr_ptes); > } > } > > -- > 2.30.2 > Thanks Barry