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 3130AC41513 for ; Mon, 31 Jul 2023 09:29:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6DC45280021; Mon, 31 Jul 2023 05:29:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 68A8728001A; Mon, 31 Jul 2023 05:29:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5792E280021; Mon, 31 Jul 2023 05:29:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 48F4C28001A for ; Mon, 31 Jul 2023 05:29:04 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1A5E5B1791 for ; Mon, 31 Jul 2023 09:29:04 +0000 (UTC) X-FDA: 81071383008.21.375F88B Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf22.hostedemail.com (Postfix) with ESMTP id CA74EC000F for ; Mon, 31 Jul 2023 09:28:58 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf22.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690795742; 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=0VFCjZBFbEMCP09Y6sGpIs4+nKdhkVP3sOjVHZslA7w=; b=jfkEc0Gsx4qfggfrdUDzZOxpaQk1j46SYUonRSvK1CzoxGQp4YRSlbOuhKrXFafYPDcrqw 9w+fM2jKyjKS5CL+yUWB/L8kChxuFJS6meem/Oaee7kFhhMw+0ov7SAscsdZ8BGFuD+QHB FMejw1e2mN7W4vB+kkLAnVy85z2qQsY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf22.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690795742; a=rsa-sha256; cv=none; b=GTGt65iWoavNxIHbSbv6MPFmOJANlEXlAsnTIR5LlFT4dQcF8yNPqwuzSSW4oZiQsMkpnr F9Ep3NcZljTGOcKEixBobLD3gnhszZXWPTfdk7sZSlKHdc/dBPVPdobwC5qbw6ST7mGqfW v8P9Mj366yQWPrWePUxDysxFAmBxdDQ= Received: from dggpemm100001.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4RDtBf1XbkzNmbm; Mon, 31 Jul 2023 17:25:30 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemm100001.china.huawei.com (7.185.36.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Mon, 31 Jul 2023 17:28:54 +0800 Message-ID: Date: Mon, 31 Jul 2023 17:28:53 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: [PATCH 4/4] arm64: tlb: set huge page size to stride for hugepage Content-Language: en-US To: Barry Song <21cnbao@gmail.com> CC: Andrew Morton , Catalin Marinas , Will Deacon , Mike Kravetz , Muchun Song , Mina Almasry , , , , , , , References: <20230731074829.79309-1-wangkefeng.wang@huawei.com> <20230731074829.79309-5-wangkefeng.wang@huawei.com> From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm100001.china.huawei.com (7.185.36.93) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: CA74EC000F X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: qb6ip3hbcng3oo7gaa3kfbjkjmddmh6u X-HE-Tag: 1690795738-416068 X-HE-Meta: U2FsdGVkX18ZobtLVVE+xF4iHHYIVrxtQZbMuHUa1xCmzuJu9hVn7Fxdh9prVjSFUdN/+r+8tuBfZoMSbRAYthOmrhEqaTPV2/AIBdmz+bhD4Xdq1bg6fGZGmN8Bb0u+lK1AGjvFWao45zDMdZ0Sj8dRasL4hzs/4DKaaMfSU7Axcv0j8LVgKD2w+enzE5m4zBQI89VOIUSrRsLzhi7A1EdG/wmyksmGbl+GkEm1jPmtsvlJDg0jDEelwnCU1Qg3owvhIUp8cZr1Iwl2jpFSIHW/JeHGmBplF6elTlpTV0K65Fb0Ih7ZKeiYNCQh2c6INj0WQhDEQ9YPyXyXxzkkMudpNDlyYdQLFQ2sUZ/Zf7PQgYsNGoFqiCs92Vu52LrSRplDqpZdGE73/XSCOapqjq6FsrHKZXi12V9Z5fuPVDaQ2rvgTnsuP5VObcFdxJKZXOaqaH8C9retmAACfIzTmBY6qS99a4++igyb1DEFEcRFlL0CX0fXp7W4AFJcOMsir3X2ka/P8pMhOWJBIAXCJwGBQLUX3FgzRLIPhpASoNqseFyliTd9XEdcBm7gB2aIlKHqH58DBkcIZM3NodjaYBKDelUrU1ybeiyNju+SrMsSy3cemXj7RtBZhmrS/fSMiWfXG1oKZz3sqHqKxQjN1N82NuhxUEp+Qkym1rxIItsXLY5rNCdcTaaLtw9DgEKu+3HWWRIPPP/vcMo43V24Vb/F9kWFUeAoTYOhb0dTUB4ctCf1wm7qlq8pj3wSBOk2i4FVXBfLJEkfPqRU+Yc90PJ0iPbYt4fd12sEMzNVKPwowL3j/tiXRayTxEA56Xl+wpS5v75EF/8mSWFc9UNNFYISqNrgRXiq/j/COhBEKf1Vs12Y3dba7y0Bk45TKPxybwkusUWxbZRA5BKxTYp/NsIRWh6wiSn9U98fqmbcY8iMgmQNsjBeBNoBYPmOytFxkzvx/k5qYZq18gtzwPV 5yilYS/6 QqZbBXXNqZdHAI6J4DxNcd6VzKPiUL1NTHysnX7YYtMOpp7/q3AjGuqUrRkMxP4Zj1MA9hv1ENSYR7LYq+rfbXGM05MGe0Udg6cFcD2f8ISLIN9zBT16mHVG+oD8arxdfPK3WQb+UF8jMDQExq6dmvHix/yTYwbN9ETaLsB7sOwNRUdtTAfD2J86iwg== 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 2023/7/31 16:43, Barry Song wrote: > On Mon, Jul 31, 2023 at 4:33 PM Barry Song <21cnbao@gmail.com> wrote: >> >> On Mon, Jul 31, 2023 at 4:14 PM Kefeng Wang wrote: >>> >>> It is better to use huge_page_size() for hugepage(HugeTLB) instead of >>> PAGE_SIZE for stride, which has been done in flush_pmd/pud_tlb_range(), >>> it could reduce the loop in __flush_tlb_range(). >>> >>> Signed-off-by: Kefeng Wang >>> --- >>> arch/arm64/include/asm/tlbflush.h | 21 +++++++++++---------- >>> 1 file changed, 11 insertions(+), 10 deletions(-) >>> >>> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h >>> index 412a3b9a3c25..25e35e6f8093 100644 >>> --- a/arch/arm64/include/asm/tlbflush.h >>> +++ b/arch/arm64/include/asm/tlbflush.h >>> @@ -360,16 +360,17 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma, >>> dsb(ish); >>> } >>> >>> -static inline void flush_tlb_range(struct vm_area_struct *vma, >>> - unsigned long start, unsigned long end) >>> -{ >>> - /* >>> - * We cannot use leaf-only invalidation here, since we may be invalidating >>> - * table entries as part of collapsing hugepages or moving page tables. >>> - * Set the tlb_level to 0 because we can not get enough information here. >>> - */ >>> - __flush_tlb_range(vma, start, end, PAGE_SIZE, false, 0); >>> -} >>> +/* >>> + * We cannot use leaf-only invalidation here, since we may be invalidating >>> + * table entries as part of collapsing hugepages or moving page tables. >>> + * Set the tlb_level to 0 because we can not get enough information here. >>> + */ >>> +#define flush_tlb_range(vma, start, end) \ >>> + __flush_tlb_range(vma, start, end, \ >>> + ((vma)->vm_flags & VM_HUGETLB) \ >>> + ? huge_page_size(hstate_vma(vma)) \ >>> + : PAGE_SIZE, false, 0) >>> + >> >> seems like a good idea. >> >> I wonder if a better implementation will be MMU_GATHER_PAGE_SIZE, in this case, >> we are going to support stride for other large folios as well, such as thp. >> > > BTW, in most cases we have already had right stride: > > arch/arm64/include/asm/tlb.h has already this to get stride: MMU_GATHER_PAGE_SIZE works for tlb_flush, but flush_tlb_range() directly called without mmu_gather, see above 3 patches is to use correct flush_[hugetlb/pmd/pud]_tlb_range(also there are some other places, like get_clear_contig_flush/clear_flush on arm64), so enable MMU_GATHER_PAGE_SIZE for arm64 is independent thing, right? > > static inline void tlb_flush(struct mmu_gather *tlb) > { > struct vm_area_struct vma = TLB_FLUSH_VMA(tlb->mm, 0); > bool last_level = !tlb->freed_tables; > unsigned long stride = tlb_get_unmap_size(tlb); > int tlb_level = tlb_get_level(tlb); > > /* > * If we're tearing down the address space then we only care about > * invalidating the walk-cache, since the ASID allocator won't > * reallocate our ASID without invalidating the entire TLB. > */ > if (tlb->fullmm) { > if (!last_level) > flush_tlb_mm(tlb->mm); > return; > } > > __flush_tlb_range(&vma, tlb->start, tlb->end, stride, > last_level, tlb_level); > } > >>> >>> static inline void flush_tlb_kernel_range(unsigned long start, unsigned long end) >>> { >>> -- >>> 2.41.0 >>> >> >> Thanks >> Barry