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 1EF9BC636D7 for ; Fri, 3 Feb 2023 14:31:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B283B6B0075; Fri, 3 Feb 2023 09:31:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AB14C6B0078; Fri, 3 Feb 2023 09:31:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92BE16B007B; Fri, 3 Feb 2023 09:31:07 -0500 (EST) 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 81FEF6B0075 for ; Fri, 3 Feb 2023 09:31:07 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 46466C10F2 for ; Fri, 3 Feb 2023 14:31:07 +0000 (UTC) X-FDA: 80426217774.02.77FBABF Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by imf09.hostedemail.com (Postfix) with ESMTP id 32A8A140018 for ; Fri, 3 Feb 2023 14:31:03 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ofi3PSph; spf=pass (imf09.hostedemail.com: domain of shiyn.lin@gmail.com designates 209.85.215.175 as permitted sender) smtp.mailfrom=shiyn.lin@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=1675434664; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eHbVXss0kJDIvbivFVNdAPcUoh10/m7Af9w1E/7lq7A=; b=2jEBUtrPv2519b0CBWav5g3vGyXWX9k3OTt0MPXNoyCkmy6OgfSGvrr0F5lhll7mu8dgK/ HsW4NbCkXkUS9st2waSsHkmn9+w2yUv9XrsfNS8+z5zznOn+lmDd0BgwUIo7/mAyYP1Zo8 LIhv8C2VJ5ruVzN65r6PBA7fCAgfWAE= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ofi3PSph; spf=pass (imf09.hostedemail.com: domain of shiyn.lin@gmail.com designates 209.85.215.175 as permitted sender) smtp.mailfrom=shiyn.lin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675434664; a=rsa-sha256; cv=none; b=mvSqjbt2cCDMWGgNngQMWtHuqiag+trYbkHnUGtJBlKPnUj+87z5NJ6FZf9mfSkgeEr1Kn g5ex5w2P3M+Wo/9ut8ca9wql3MtpkjT5rgp8+QOCesLJCnhpi6tBrilfZFf08Z1lXvWbJN SWaFvK4eRpVmgeqHNTdx1y0LvQoXqag= Received: by mail-pg1-f175.google.com with SMTP id 141so3781890pgc.0 for ; Fri, 03 Feb 2023 06:31:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=eHbVXss0kJDIvbivFVNdAPcUoh10/m7Af9w1E/7lq7A=; b=Ofi3PSphKR/DYfbx8dVbYEWhH8mN+eq6I8ysLlFhLl6KNrkMLQ51/DSfBVox71Cc7+ QNEPl1JseglojXj3aG20yT7Fd1RknYnGcVfn8zsBl6sbCC0AJHTPmPNRdBC93tUska0L SLVBgMSH+kY1vthyRXOKk/gfgNoJOLiR6hoHhAON1QML04cTCV0gSFpmBrGE4WV5rDPR JjHTv9EriZ9h/JiwL3feaRIzfvqVLPm5W9yjgxO0UXQ/eLvFzkh4tJDeNLZhB9y2J5UL XKR0FdjjIRLilbM/syMgWYweBPHhV4wulAECc5ZAkzV81pX50WiERtFBcjjdHaFcfHJ2 synA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eHbVXss0kJDIvbivFVNdAPcUoh10/m7Af9w1E/7lq7A=; b=pf9UewZrbVH+klHkEef6Yi6bpypaZFkMIKrtEQIynChjkZFD7wcfsCQrG14wqK7oD7 gAKP68GEpmg9HQ5d+u4lceFYw/LCfdVBpE1eLt2nzWjmVmS1OPQk6MImamDfiYdpCTJ+ kZcFzogfkgP6UqLsxBcH1NCvvVgCpU3QB8wiBTGOiGnKSAPnrZy0YU/SnhT/SpSaqdVI uH1iVX6Tu82CLM7+nGRKqrSONsU+2fjEtDhDsLFucLStV0FtM5YWNpkirABb8uRb5V81 c69Gp1etUfwOH8NeR6Bkw/j26BTaWeriDZx9QOpuPAmsPkjqenxtu4xVABodolLARjCn 3ITw== X-Gm-Message-State: AO0yUKUUzzYCD94p1bPrKVkG4EfJY7bC01mDM+VXVaSdNvxTuhKvUic5 ZLGThFZT7FWeXyV8nF0Lhs4= X-Google-Smtp-Source: AK7set8TX6YHlllrNenMQV7LbCC+JnAo6BanooMbBJVYbuai1WyT1jfOOMtEPVn17T0sHvD3QBF3Qg== X-Received: by 2002:aa7:983d:0:b0:592:453f:473f with SMTP id q29-20020aa7983d000000b00592453f473fmr9525982pfl.6.1675434662878; Fri, 03 Feb 2023 06:31:02 -0800 (PST) Received: from strix-laptop ([123.110.9.95]) by smtp.gmail.com with ESMTPSA id x190-20020a6263c7000000b00593a1f7c3dbsm1858453pfb.10.2023.02.03.06.31.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 06:31:02 -0800 (PST) Date: Fri, 3 Feb 2023 22:30:58 +0800 From: Chih-En Lin To: "Yin, Fengwei" Cc: willy@infradead.org, david@redhat.com, linux-mm@kvack.org, dave.hansen@intel.com, tim.c.chen@intel.com, ying.huang@intel.com Subject: Re: [RFC PATCH v3 3/4] mm: add do_set_pte_range() Message-ID: References: <20230203131636.1648662-1-fengwei.yin@intel.com> <20230203131636.1648662-4-fengwei.yin@intel.com> <28b7e294-8074-47ee-88a2-51890a035559@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28b7e294-8074-47ee-88a2-51890a035559@intel.com> X-Rspamd-Queue-Id: 32A8A140018 X-Stat-Signature: gi13d81iij18dh7a7unqyww4td9ct9s8 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675434663-253316 X-HE-Meta: U2FsdGVkX19fbs4/TsJqmt/oE3BmSNNUU0zei/QMRo83XxsHDQvMazltNGvwmrJtE4lSvpgVgNoP8waV4DJmubNI2mdnT0ZDsMgzRWDmFizq1vpxptaVpPjEpdtE+TPcevocGct0uGVbB+6B8BcYT74hxhH11CXvn6MxH99IjP6BnqdFnFl0fk6z5a0E7nWCH5zvQ4vc3CRtd8jTCpl5Lg+ZiAYWGjo7EfC5Dll01mxRHcNYmh9dw3vWmxT6weZbvMHXZx/x3ew8MvAlJfokyQq2A9cV3vDuWCWJ+VDx4Bz+K6dEjR7UexEAPDkqDTvJB/s1dkZkSb8pMy5+Oju5DiUOEUF7an7vnWgTrHIWoah+0cs4zkbZOiktVsD7o7uDTLmxWnXGHyqVOrBjK/mZjVH8pFbsw8PRuXw0ZNJ1aWumChl9zFH4RfrwzPgvb1l2BRBn50G/pJT0CrL7DIVBtMY0+vlXEQG4LMgNKrTLaK0dkPtkED3GJiIJw6MPbCZY5zkJg22XABJunpEgzy5iNBcFTlkbT0vscYM4SdVS9KNAm0uDzuAH+OhtPrChQ4tn7Zqbq0HO5b7WLtGBrdl8UrdT2PD7pVfGJp17ntMw2fdDFFD2Neeh7CfoZxR0txPzC3rXstJeQf64DB6eauAT7GRlGU7aENMipi/+bDZwF+AySL0DqmmWhJY345602LGCM+ssK8oJDuQ+Gul6NahW0DUTQt8JO6ampJhN507fjgWU9CNTVPFzOykkeesxANGOjFlTWOjVL9PsZLztMAY2NcNiCb4Y+3G0TLRg+0D9wgjjYZbo2cY//9+5NGC4VZ0mI7AvEJJUkfpAGWJki5vH+Sv8v4ejsMpujYqFoSReFulw08GVU+pIAxyDARkz9rGcBqZwbpf4kPsDQQB6yVqJaw6WuzZGNVab2Bt2fATjGmuLHhKIJVr/GySo8wucFywflkITU7otVc3D4ILvflP K0PFcquF zDve8hypfqJSUHfbB/bWQBqwDmTvT/Hac8/uUeq+ECyt9/ZG77JlEurdaL1MNcQFzQuciQ/RhegLT1kYp/mwH2y7CWYdCwDidlToPO7cnIXFc4o+sK5P2MtCPNNPTD4BHU8QYlFXRL6pwv4wcbJ8cixdnbNlkZ5y3lu+7J6HXybOiQN3Oo6w5TRXhLjPJLY/zC2gOk4xHMSpkn/leuvYsIn5AOppBf1fow5zasGOva4F/H7KSNOVRiyL4GK0bf6PcrmNeK+cYPL+u9dTcvSU6/blMGT1HTSxk1P5+QWubGkPccp1G5aM54TkgS8nMKiaEA0YZ88G4W+yKvsT5eAv8tZJMIbZAG2+/J3pMo0WOfrIBkqrhjGT4iTWwLc/6f24VVi+Kp/I8bhBE8sMgO4LfUIHxr09PoqYnz/vxZ6HHOfUJvntw8n2Sr7++WZUbfOBP7SKhbuVrQgWmvQdFMrdekaqHcjzqiumGqTcz6nvenh29wJgzd0hsPay8pnso5osPHoOTrdluzE8NWOOELjrV66n+DX2m3+tG3Nk4vmfiKiFMw9I= 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: On Fri, Feb 03, 2023 at 09:38:15PM +0800, Yin, Fengwei wrote: > > > On 2/3/2023 9:32 PM, Chih-En Lin wrote: > > On Fri, Feb 03, 2023 at 09:16:35PM +0800, Yin Fengwei wrote: > >> do_set_pte_range() allows to setup page table entries for a > >> specific range. It calls folio_add_file_rmap_range() to take > >> advantage of batched rmap update for large folio. > >> > >> Signed-off-by: Yin Fengwei > >> --- > >> include/linux/mm.h | 3 +++ > >> mm/filemap.c | 1 - > >> mm/memory.c | 59 ++++++++++++++++++++++++++++++---------------- > >> 3 files changed, 42 insertions(+), 21 deletions(-) > >> > >> diff --git a/include/linux/mm.h b/include/linux/mm.h > >> index d6f8f41514cc..93192f04b276 100644 > >> --- a/include/linux/mm.h > >> +++ b/include/linux/mm.h > >> @@ -1162,6 +1162,9 @@ static inline pte_t maybe_mkwrite(pte_t pte, struct vm_area_struct *vma) > >> > >> vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page); > >> void do_set_pte(struct vm_fault *vmf, struct page *page, unsigned long addr); > >> +void do_set_pte_range(struct vm_fault *vmf, struct folio *folio, > >> + unsigned long addr, pte_t *pte, > >> + unsigned long start, unsigned int nr); > >> > >> vm_fault_t finish_fault(struct vm_fault *vmf); > >> vm_fault_t finish_mkwrite_fault(struct vm_fault *vmf); > >> diff --git a/mm/filemap.c b/mm/filemap.c > >> index f444684db9f2..74046a3a0ff5 100644 > >> --- a/mm/filemap.c > >> +++ b/mm/filemap.c > >> @@ -3386,7 +3386,6 @@ static vm_fault_t filemap_map_folio_range(struct vm_fault *vmf, > >> > >> ref_count++; > >> do_set_pte(vmf, page, addr); > >> - update_mmu_cache(vma, addr, vmf->pte); > >> } while (vmf->pte++, page++, addr += PAGE_SIZE, ++count < nr_pages); > >> > >> /* Restore the vmf->pte */ > >> diff --git a/mm/memory.c b/mm/memory.c > >> index 7a04a1130ec1..3754b2ef166a 100644 > >> --- a/mm/memory.c > >> +++ b/mm/memory.c > >> @@ -4257,36 +4257,58 @@ vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page) > >> } > >> #endif > >> > >> -void do_set_pte(struct vm_fault *vmf, struct page *page, unsigned long addr) > >> +void do_set_pte_range(struct vm_fault *vmf, struct folio *folio, > >> + unsigned long addr, pte_t *pte, > >> + unsigned long start, unsigned int nr) > >> { > >> struct vm_area_struct *vma = vmf->vma; > >> bool uffd_wp = pte_marker_uffd_wp(vmf->orig_pte); > >> bool write = vmf->flags & FAULT_FLAG_WRITE; > >> + bool cow = write && !(vma->vm_flags & VM_SHARED); > > > > Why don't use is_cow_mapping()? > > Is there anything messed up with VM_MAYWRITE? > My understanding is it's not related with the mapping. It's related with > what operation triggers fault here. Say, if it's a writable mapping, and > if the read operation triggers fault here, no cow or maybe_mkwrite() needed > here. Thanks. Sorry, I didn't describe the thing properly. It makes sense for the relationship with the write/read fault. I'm just wondering if "!(vma->vm_flags & VM_SHARED)" is enough to determine the COW page? And, I also found it in do_fault(). Like, copy_present_pte() use is_cow_mapping() for COW page and "vm_flags & VM_SHARED" for shared mapping. So, I looked up the commit that introduced the is_cow_mapping(), 67121172f9753 ("Allow arbitrary read-only shared pfn-remapping too"). Here is the commit message: " The VM layer (for historical reasons) turns a read-only shared mmap into a private-like mapping with the VM_MAYWRITE bit clear. Thus checking just VM_SHARED isn't actually sufficient. So use a trivial helper function for the cases where we wanted to inquire if a mapping was COW-like or not. " hmm, but it is v2.6.15. So is "vm_flags & VM_SHARED" enough to check the COW page now? Thanks, Chih-En Lin