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 A2F40C25B10 for ; Fri, 10 May 2024 16:36:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 317856B00CC; Fri, 10 May 2024 12:36:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29ECC6B0100; Fri, 10 May 2024 12:36:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18E166B0101; Fri, 10 May 2024 12:36:47 -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 EAF926B00CC for ; Fri, 10 May 2024 12:36:46 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 90782A2679 for ; Fri, 10 May 2024 16:36:46 +0000 (UTC) X-FDA: 82103040012.10.A468876 Received: from out0-218.mail.aliyun.com (out0-218.mail.aliyun.com [140.205.0.218]) by imf10.hostedemail.com (Postfix) with ESMTP id 0543AC001E for ; Fri, 10 May 2024 16:36:42 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=antgroup.com header.s=default header.b=pu5eooT3; spf=pass (imf10.hostedemail.com: domain of libang.li@antgroup.com designates 140.205.0.218 as permitted sender) smtp.mailfrom=libang.li@antgroup.com; dmarc=pass (policy=quarantine) header.from=antgroup.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715359004; 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=qtTzD4p4/mI5FQfHMAQ4AseA2ZJSqFbFGgw9hxpmGnA=; b=2jQHDODW73Vx768/JA7bPu1tHsuX3vfTPoPcVu78DodifNGomAIwOElVd9SNMqdvJep3Va DDgH+zXkKywK/9i0JGTTdNAVhX8fkWOS0jSOL9xbCPS42/q4j49WJAq8yZ+CvYf+E+la4K n0T0ggkUZuydgXGrRyJLRlqBr/dSvhU= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=antgroup.com header.s=default header.b=pu5eooT3; spf=pass (imf10.hostedemail.com: domain of libang.li@antgroup.com designates 140.205.0.218 as permitted sender) smtp.mailfrom=libang.li@antgroup.com; dmarc=pass (policy=quarantine) header.from=antgroup.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715359004; a=rsa-sha256; cv=none; b=QpsGV8jct2D2I/w5snzmwraVlaWGXAdm0Uc07O5K5kZNQ+8k1YE+V4sbacPElKR4gYPvPd T7arLNbeNtXRglykBXmcJhTwams0F9HLENlzF+1BIZ7eF/RQNEkG3heuf3qabZkKgneRtT iSN4jBN2S2oRA1kS+37wU3JWe2HZbAU= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1715358999; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=qtTzD4p4/mI5FQfHMAQ4AseA2ZJSqFbFGgw9hxpmGnA=; b=pu5eooT3U2RWfu50k56IjqA0Wqko1T6DmtXSN21RFmgQwWanO7GHNn41/CxeNFUauQzgrlOjVsmUGokOXe87zqhYGpUrbcB26G82MlIL4jeqY9uZFN/6jvbnuhJBEzUJc9wqyIuLop5aycyPIVmOwm6W7Eu/EWXNBV6QmA/60S0= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018047212;MF=libang.li@antgroup.com;NM=1;PH=DS;RN=16;SR=0;TI=SMTPD_---.XYAMMf6_1715358997; Received: from 30.39.184.43(mailfrom:libang.li@antgroup.com fp:SMTPD_---.XYAMMf6_1715358997) by smtp.aliyun-inc.com; Sat, 11 May 2024 00:36:38 +0800 Message-ID: <41acfd35-69b4-41bc-a45b-4426d5110077@antgroup.com> Date: Sat, 11 May 2024 00:36:35 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/5] mm: Add update_mmu_tlb_range() To: Ryan Roberts , akpm@linux-foundation.org, chenhuacai@kernel.org, tsbogend@alpha.franken.de, paul.walmsley@sifive.com, palmer@dabbelt.com, chris@zankel.net, jcmvbkbc@gmail.com Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, david@redhat.com, ioworker0@gmail.com, libang.linux@gmail.com, baolin.wang@linux.alibaba.com References: <20240506155120.83105-1-libang.li@antgroup.com> <20240506155120.83105-6-libang.li@antgroup.com> Content-Language: en-US From: "Bang Li" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 0543AC001E X-Stat-Signature: gy6p3wfbou9tarqattc6n8rd1rz3ukeo X-HE-Tag: 1715359002-165236 X-HE-Meta: U2FsdGVkX183tt33VzNbEL+eN9XQ/pyCNJnEIO7Z9HxXfiXzTACgHNwCq4mJqYHhvJqulretV2oqIYRo0bjZKjL7aWnCMlsGGXeJVna20BrCDv7opbUFsQaLtdx1A63VSXPX1pLRDmnLxecvPzeL0nLOomvo7MRitsH/ETO5KfpIwmWc53Nhg1ZQmKL8qegC/mUUhVUzy+rZt5qmXWHPB6Hm6CmEsgPEkyFtJ9rMF/OuB2sG5tJ1FjGyxbktJ7WnwRGHUF0ykmWuPHdAiWXZZlnByxELs6BzqHkazDilNC8Mw0oAby7sPIszPcJzsp3sM2uINo5nuJ8SKPC7HTeDlEfb7QLn8ztc8sjmPM3Pwz4h0Cgc1V1t6EDY8sjPN8wdyC7mdnMRcpPgyKuYvxjLQAIGvRSKC5Cg6O1mtgqI5NFChn1ycDQmx57LStJGowUwgU5mmnEWqz2gpdwE+P4dKGUw6HFvgvG6ZMgEEtY1XuvSw2FEaOWRc2vEnjK7ouQARrKkkElW7gbOjuXG4gUHk9jTaCy+x2n9Tr4znrSn4gESV1+az1BOci7S0CCrSkWtjgkPJw956Hb6Z5gZPp1eYkZXT/6djuIrlK/6I9oaWoWk7e8cjKykEj1j3CuLLLQtCjy3NQ6X6SGcCZvlPvdsfpNmtqIgrCFBwAYIwJ9BuJj+2JXidebNZWh4rr7gjulsX5gnuTo0ZMnoFCs9RLh8THPCs6jOP8w9wPMJI2x7Lc+Dh+42r5dvuH7PH06jwB0HAXJ3hgObbsyzujW9x6FsmhzZcm1VMWSxZfUN0GuZOGgrJBKe+sraCgv8113S/SqC3us1ULRTEEeZj8Jj8GpDQaXaGrIfgrlZhJ3fzVCSfi1jzHnKUBbBGHQ2sqTdYPXc79ABjKZtbfG+p1weapip8TxszL899jQzrTLF9/NYGZQ6afP0OqNM5bLU1AvGiEjBpN7xUudRQx34cTASKEo TVFglO0S C0wvz/stzdU6s2euaWiKLWNVLm7VSe/iM8ZwMigKjyL/lHTq55zDjlbSyphb9HYLNRs9RCt2v8iG4pcMFsU6ntOMFLnHVLxRkpEDtxZuZuTQpq6AovMBLbkRc5Xz0Q0HMaTKQm7J4rR1qgTX5pyydExyljCjGByzeuyrpwj67S4tMHu7xJYRDtmKklqTw+FotbzUMXCF99pLgNBYdqhZxn4aAxrPt9NkW5FIMAnnZfkjkx3xg2NL2+DQPGlaCjL79ohEsvZk50pBfTnJLp7rxBQIOZJwK6dQc2+gxSIcshxrfD1NKThNrtU/LaYPlUCeFeRiBLvHQdrfOwyoUCscfDyC+aVvkBYFLQe06p48pm9AY55jXUpFuV6QVaJQBq4nsx6FrmuhgdVsmYjXbVeG/jK2WHCGFWz62BZRwAcycdgEiN5kNBWt817iDU54VVyFrcV89YDnCsOG5fdwuYGIWVkqGuQ== 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: Hi Ryan, Thanks for you review! On 2024/5/10 17:05, Ryan Roberts wrote: > On 06/05/2024 16:51, Bang Li wrote: >> After the commit 19eaf44954df ("mm: thp: support allocation of anonymous >> multi-size THP"), it may need to batch update tlb of an address range >> through the update_mmu_tlb function. We can simplify this operation by >> adding the update_mmu_tlb_range function, which may also reduce the >> execution of some unnecessary code in some architectures. >> >> Signed-off-by: Bang Li >> --- >> include/linux/pgtable.h | 8 ++++++++ >> mm/memory.c | 4 +--- >> 2 files changed, 9 insertions(+), 3 deletions(-) >> >> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h >> index 18019f037bae..869bfe6054f1 100644 >> --- a/include/linux/pgtable.h >> +++ b/include/linux/pgtable.h >> @@ -737,6 +737,14 @@ static inline void update_mmu_tlb(struct vm_area_struct *vma, >> #define __HAVE_ARCH_UPDATE_MMU_TLB >> #endif > > Given you are implementing update_mmu_tlb_range() in all the arches that > currently override update_mmu_tlb() I wonder if it would be cleaner to remove > update_mmu_tlb() from all those arches, and define generically, removing the > ability for arches to override it: > > static inline void update_mmu_tlb(struct vm_area_struct *vma, > unsigned long address, pte_t *ptep) > { > update_mmu_tlb_range(vma, address, ptep, 1); > } Agreed! Thank you for your suggestion, I will modify it in the next version. > >> >> +#ifndef __HAVE_ARCH_UPDATE_MMU_TLB_RANGE >> +static inline void update_mmu_tlb_range(struct vm_area_struct *vma, >> + unsigned long address, pte_t *ptep, unsigned int nr) >> +{ >> +} >> +#define __HAVE_ARCH_UPDATE_MMU_TLB_RANGE >> +#endif > > Then you could use the modern override scheme as Lance suggested and you won't > have any confusion with __HAVE_ARCH_UPDATE_MMU_TLB because it won't exist anymore. Yes, use update_mmu_tlb_range to implement update_mmu_tlb, we only need to define the update_mmu_tlb_range macro. > >> + >> /* >> * Some architectures may be able to avoid expensive synchronization >> * primitives when modifications are made to PTE's which are already >> diff --git a/mm/memory.c b/mm/memory.c >> index eea6e4984eae..2d53e29cf76e 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -4421,7 +4421,6 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf) >> vm_fault_t ret = 0; >> int nr_pages = 1; >> pte_t entry; >> - int i; >> >> /* File mapping without ->vm_ops ? */ >> if (vma->vm_flags & VM_SHARED) >> @@ -4491,8 +4490,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf) >> update_mmu_tlb(vma, addr, vmf->pte); >> goto release; >> } else if (nr_pages > 1 && !pte_range_none(vmf->pte, nr_pages)) { >> - for (i = 0; i < nr_pages; i++) >> - update_mmu_tlb(vma, addr + PAGE_SIZE * i, vmf->pte + i); >> + update_mmu_tlb_range(vma, addr, vmf->pte, nr_pages); > > I certainly agree that this will be a useful helper to have. I expect there will > be more users in future. Thank you for your affirmation. Baolin’s "add mTHP support for anonymous shmem" series[1] can also use this function to simplify the code. [1] https://lore.kernel.org/linux-mm/cover.1714978902.git.baolin.wang@linux.alibaba.com/ Thanks, Bang > >> goto release; >> } >>