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 BF5C3C369DC for ; Wed, 30 Apr 2025 06:44:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 839F86B00BB; Wed, 30 Apr 2025 02:44:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E8906B00C1; Wed, 30 Apr 2025 02:44:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6613F6B00C4; Wed, 30 Apr 2025 02:44:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3D22D6B00BB for ; Wed, 30 Apr 2025 02:44:42 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B1CEF1A07A3 for ; Wed, 30 Apr 2025 06:37:53 +0000 (UTC) X-FDA: 83389754826.28.73D2017 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf20.hostedemail.com (Postfix) with ESMTP id 01AFD1C0011 for ; Wed, 30 Apr 2025 06:37:51 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf20.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745995072; a=rsa-sha256; cv=none; b=IaZRMvtVSRthNboZjBvh+xs/EJQRCJuW/lYqCaMuWjisxcFLjJCAPjmi9CWndLtp3xMLvZ +fq6bP2tfN55mQxXqXgp8/WW5kB8RkqxbkE1icAylBDY1873ktC2oNFLz/R3+0UQgiG6ir lSIfyU7kB+b2PvAaQv0CILhXWs73igw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745995072; 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; bh=hswNx1yk2khP3jCgiHhYfeW+HZiM1IKrwRhJc5vHisk=; b=Tj9oeQgCuVOSF6yzrWpXCftlVhO+dXXQItuPGYMS42EsbjRuOKf01msx4Xus5HH3w7wdXA bDqbOFHwVrgL8uew/krQVdv5n0n5rY8FRdgaInMvYxpAbgyaY6kzKluHlxegE2iGBqNleM U9SfGfcnjKmK2Gsrb3xMf2+LdUiI4Ug= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf20.hostedemail.com: domain of dev.jain@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=dev.jain@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 27FC4106F; Tue, 29 Apr 2025 23:37:44 -0700 (PDT) Received: from [10.163.79.251] (unknown [10.163.79.251]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B72F93F66E; Tue, 29 Apr 2025 23:37:41 -0700 (PDT) Message-ID: <9687592f-ec04-410f-9fb2-9777edfe1178@arm.com> Date: Wed, 30 Apr 2025 12:07:37 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/7] mm: Optimize mprotect() by batch-skipping PTEs To: Lorenzo Stoakes Cc: akpm@linux-foundation.org, ryan.roberts@arm.com, david@redhat.com, willy@infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, Liam.Howlett@oracle.com, vbabka@suse.cz, jannh@google.com, anshuman.khandual@arm.com, peterx@redhat.com, joey.gouly@arm.com, ioworker0@gmail.com, baohua@kernel.org, kevin.brodsky@arm.com, quic_zhenhuah@quicinc.com, christophe.leroy@csgroup.eu, yangyicong@hisilicon.com, linux-arm-kernel@lists.infradead.org, namit@vmware.com, hughd@google.com, yang@os.amperecomputing.com, ziy@nvidia.com References: <20250429052336.18912-1-dev.jain@arm.com> <20250429052336.18912-3-dev.jain@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 01AFD1C0011 X-Stat-Signature: kbapphuu3z3sxc8uydaw4nreuz4eqmo6 X-Rspam-User: X-HE-Tag: 1745995071-34706 X-HE-Meta: U2FsdGVkX18mdKEfYQnrx4gwiBzrrHYnR0v3LSDvB2NJDPIWPfBoxYFPsyzVY+xNia8yj8oDOny/UPjSh4kZLKZqi/cRE81bDdEDgD62PqlvZfrju0aIvx7+TPHB/HpK1XfvQ78awSu1IzkMMW0iUIwXalcpd1Y4D2nyx0SENdK5r92Hv0gGVUCeTUpMXtJjKCaKBzGl/WX8VuFJ16qzwb0SzwfILoWyL4hIe97zx9BVRqcYJyTMmC95Hjk7UeFjW3S9rW9KpW6GzmhIh6qlZAlDFdmZ/Q5TlxTYdR707ueKHOj4Z7zmeVQ/KV0D65BrmmndkmkI7EeVcPQZV65IgjuWoOYlb8KbX9hvI4csIBTLcnhFrCWEXIWedQ5OIXJj8/lKJ2+JP/RHdZ9AdA+6OehTSmuL91U6SqWzfVZ+14H86skvBmapD44jPl4YRKF9Xl6sEmptMyABGXipRGKeSuvCBtQVPzj8rpo6FdswVA9K+qbem892cgHGiu1pLqmP/DJs1NdO+h3vWiMwoqXNJKA+zOaYkpx2ZoxDTihV6nM1xba4gUZJc4CDX43t75m46BYya8mmg1qnrrsxnKrvkG205wj28baHdMUXT73jrzClvEiM32MLhypKUxoz2M/HElHXv2+IuGq4mChIQo3xFOkWYkLYsBzI7VDYyccDO700uoGWiERaOlUSVQKmMbS5h2TjeDZNSahaaO0EZEgds6Mpxp4cl8Iott1EJ/frzuHdv4KFU1YdQhdOAbeyYPW5az4hlk3f2eKqqMQqcXKodPRu7NygCbVWneN3Ac5NIYwsARrCkYEcPZ05oHgvzV+w9jq/ZWpYx2iUgOvSgmxtp6FaC0lsgH9vWMx3f6yVbiasiDJgpEH42bVeKszZypar9K2T4L6300D5N2Q5RQC8QUIqwAfwcOXVoiYdtnViUyRjt3S+TEquHb1rDeKLeQTMEJPE2Q6gUcdJDYBTL6j L9vbig5N cGup6z6bAgRZ++BMGRlbG4fWnMsPfHVvNthwB0VO/1BZm09jrALXwfifneusaEhhEg+oznACJJDks3q149NfDJEOoPbnOF96PKej2UXdq7pXHSsuT5viaIJmx7ShAjc3uIl89K4yEhw9sI3J4lc1e0kbA87/IbU3QGli9Z/KU0b16aXJL4qs9WfYV26tEpY39+QyIv4fUj+Dm12c= 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 29/04/25 6:49 pm, Lorenzo Stoakes wrote: > Very very very nitty on subject (sorry I realise this is annoying :P) - > generally don't need to capitalise 'Optimize' here :>) > > Generally I like the idea here. But some issues on impl. > > On Tue, Apr 29, 2025 at 10:53:31AM +0530, Dev Jain wrote: >> In case of prot_numa, there are various cases in which we can skip to the >> next iteration. Since the skip condition is based on the folio and not >> the PTEs, we can skip a PTE batch. >> >> Signed-off-by: Dev Jain >> --- >> mm/mprotect.c | 27 ++++++++++++++++++++------- >> 1 file changed, 20 insertions(+), 7 deletions(-) >> >> diff --git a/mm/mprotect.c b/mm/mprotect.c >> index 70f59aa8c2a8..ec5d17af7650 100644 >> --- a/mm/mprotect.c >> +++ b/mm/mprotect.c >> @@ -91,6 +91,9 @@ static bool prot_numa_skip(struct vm_area_struct *vma, struct folio *folio, >> bool toptier; >> int nid; >> >> + if (folio_is_zone_device(folio) || folio_test_ksm(folio)) >> + return true; >> + > > Hm why not just put this here from the start? I think you should put this back > in the prior commit. > >> /* Also skip shared copy-on-write pages */ >> if (is_cow_mapping(vma->vm_flags) && >> (folio_maybe_dma_pinned(folio) || >> @@ -126,8 +129,10 @@ static bool prot_numa_skip(struct vm_area_struct *vma, struct folio *folio, >> } >> >> static bool prot_numa_avoid_fault(struct vm_area_struct *vma, >> - unsigned long addr, pte_t oldpte, int target_node) >> + unsigned long addr, pte_t *pte, pte_t oldpte, int target_node, >> + int max_nr, int *nr) > > Hate this ptr to nr. > > Why not just return nr, if it's 0 then skip? Simple! > >> { >> + const fpb_t flags = FPB_IGNORE_DIRTY | FPB_IGNORE_SOFT_DIRTY; >> struct folio *folio; >> int ret; >> >> @@ -136,12 +141,16 @@ static bool prot_numa_avoid_fault(struct vm_area_struct *vma, >> return true; >> >> folio = vm_normal_folio(vma, addr, oldpte); >> - if (!folio || folio_is_zone_device(folio) || >> - folio_test_ksm(folio)) >> + if (!folio) >> return true; >> + > > Very nitty, but stray extra line unless intended... > > Not sure why we can't just put this !folio check in prot_numa_skip()? Because we won't be able to batch if the folio is NULL. I think I really messed up by having separate patch 1 and 2. The real intent of patch 1 was to do batching in patch 2 *and* not have insane indentation. Perhaps I should merge them, or completely separate them logically, I'll figure this out. > >> ret = prot_numa_skip(vma, folio, target_node); >> - if (ret) >> + if (ret) { >> + if (folio_test_large(folio) && max_nr != 1) >> + *nr = folio_pte_batch(folio, addr, pte, oldpte, >> + max_nr, flags, NULL, NULL, NULL); > > So max_nr can <= 0 too? Shouldn't this be max_nr > 1? > >> return ret; > > Again x = fn_return_bool(); if (x) { return x; } is a bit silly, just do if > (fn_return_bool()) { return true; }. > > If we return the number of pages, then this can become really simple, like: > > I feel like maybe we should abstract the folio large handling here, though it'd > be a tiny function so hm. > > Anyway assuming we leave it in place, and return number of pages processed, this > can become: > > if (prot_numa_skip(vma, folio, target_node)) { > if (folio_test_large(folio) && max_nr > 1) > return folio_pte_batch(folio, addr, pte, oldpte, max_nr, flags, > NULL, NULL, NULL); > return 1; > } > > Which is neater I think! > > >> + } >> if (folio_use_access_time(folio)) >> folio_xchg_access_time(folio, >> jiffies_to_msecs(jiffies)); >> @@ -159,6 +168,7 @@ static long change_pte_range(struct mmu_gather *tlb, >> bool prot_numa = cp_flags & MM_CP_PROT_NUMA; >> bool uffd_wp = cp_flags & MM_CP_UFFD_WP; >> bool uffd_wp_resolve = cp_flags & MM_CP_UFFD_WP_RESOLVE; >> + int nr; >> >> tlb_change_page_size(tlb, PAGE_SIZE); >> pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl); >> @@ -173,8 +183,10 @@ static long change_pte_range(struct mmu_gather *tlb, >> flush_tlb_batched_pending(vma->vm_mm); >> arch_enter_lazy_mmu_mode(); >> do { >> + nr = 1; >> oldpte = ptep_get(pte); >> if (pte_present(oldpte)) { >> + int max_nr = (end - addr) >> PAGE_SHIFT; > > Not a fan of open-coding this. Since we already provide addr, why not just > provide end as well and have prot_numa_avoid_fault() calculate it? > >> pte_t ptent; >> >> /* >> @@ -182,8 +194,9 @@ static long change_pte_range(struct mmu_gather *tlb, >> * pages. See similar comment in change_huge_pmd. >> */ >> if (prot_numa && >> - prot_numa_avoid_fault(vma, addr, >> - oldpte, target_node)) >> + prot_numa_avoid_fault(vma, addr, pte, >> + oldpte, target_node, >> + max_nr, &nr)) >> continue; >> >> oldpte = ptep_modify_prot_start(vma, addr, pte); >> @@ -300,7 +313,7 @@ static long change_pte_range(struct mmu_gather *tlb, >> pages++; >> } >> } >> - } while (pte++, addr += PAGE_SIZE, addr != end); >> + } while (pte += nr, addr += nr * PAGE_SIZE, addr != end); > > This is icky, having 'nr' here like this. > > But alternatives might be _even more_ icky (that is advancing both on > prot_numa_avoid_fault() so probably we need to keep it like this. > > Maybe more a moan at the C programming language tbh haha! > > >> arch_leave_lazy_mmu_mode(); >> pte_unmap_unlock(pte - 1, ptl); >> >> -- >> 2.30.2 >>