Message ID | 20230731074829.79309-3-wangkefeng.wang@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:918b:0:b0:3e4:2afc:c1 with SMTP id s11csp1866769vqg; Mon, 31 Jul 2023 01:13:06 -0700 (PDT) X-Google-Smtp-Source: APBJJlF0qkL/b8SnzV58jC+/Sn3wHlEviMMYxekOsJDx2t06ietl1IqFcZIIzi50vPQzKGSQaDiD X-Received: by 2002:a05:6a21:790a:b0:131:4808:d5a1 with SMTP id bg10-20020a056a21790a00b001314808d5a1mr7901571pzc.28.1690791186096; Mon, 31 Jul 2023 01:13:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690791186; cv=none; d=google.com; s=arc-20160816; b=JxsINs70SbB73Orw3tR8qzDfdNeK2dc/Qksdr8hG3PN7nOUcxmy7verYvxBF4IqfEr ndx/By/DtJYwJ7cGNnQR297MVcXG8tfrx5kW2Bau/G86kP1b0azrnKGWupU8xdApNytj s2CEhYFU8BjCpH2+IzjsuknxrBBMAT8eyBhJyM7QjXTi3OZcb8qCVX1sdjhbfir8Uv7J buTVfZLQv6OEC8Uu0iJx9cZtXYV4lsfVA+aJioi8COLgI7WEn+CB+kTNZ/vLG75cevOC KP7vNaQRwC/MFI91HaQjW8YOLKpjhNEfIAeyp/sM2nfAwUgRMErnh/qz8ig9vOgxp+Vv AWfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=QnjtTek5fZ/4QtwvL41dNaJX0C5UFKPKxH+gNlzHWXo=; fh=pWGPqOKfNGLee4HdbDJvfX9Bibz+qaOAq2a2PB8WHto=; b=oIZ+DYLqkCSbJyzrv5QNTBuPpTvNXmgpZWkDw3xleuYvN6lsuGD1YxL5EZMRhwVOMm 2RMIUZWNiTu1dsCJmaS2NTcTbeXUhxUPiSHY95rU0Dfz5qFCF1ocsOxeAtBsAD14uyOI 2ivI9XliENn9hkFa1HqyTCfbYR68gDsjaVGvXCYwlFeS70NOckyc6j0xc9T8UIWy1//C Cdfhz0BEaguKGsSzJlpYp9FNtUogcY6qMovBbrdKpw8uh/THCbNHHpfZhJAxR4NsSZot wE6aFtlwpueZIucEZOmWrvb/FkVH7HXe+kcK5VqjqrW7VBkXx39ZFuGc6YpPr/l/PpJg OPJw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q7-20020a170902a3c700b001bb162e944dsi3829295plb.51.2023.07.31.01.12.52; Mon, 31 Jul 2023 01:13:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231401AbjGaHjc (ORCPT <rfc822;dengxinlin2429@gmail.com> + 99 others); Mon, 31 Jul 2023 03:39:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229722AbjGaHjU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 31 Jul 2023 03:39:20 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B768C10E for <linux-kernel@vger.kernel.org>; Mon, 31 Jul 2023 00:39:17 -0700 (PDT) Received: from dggpemm100001.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4RDqmD2YBwztQSD; Mon, 31 Jul 2023 15:35:56 +0800 (CST) Received: from localhost.localdomain.localdomain (10.175.113.25) 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 15:39:15 +0800 From: Kefeng Wang <wangkefeng.wang@huawei.com> To: Andrew Morton <akpm@linux-foundation.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Mike Kravetz <mike.kravetz@oracle.com>, Muchun Song <muchun.song@linux.dev>, Mina Almasry <almasrymina@google.com>, <kirill@shutemov.name>, <joel@joelfernandes.org>, <william.kucharski@oracle.com>, <kaleshsingh@google.com>, <linux-mm@kvack.org> CC: <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, Kefeng Wang <wangkefeng.wang@huawei.com> Subject: [PATCH 2/4] mm: mremap: use flush_pmd_tlb_range() in move_normal_pmd() Date: Mon, 31 Jul 2023 15:48:27 +0800 Message-ID: <20230731074829.79309-3-wangkefeng.wang@huawei.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230731074829.79309-1-wangkefeng.wang@huawei.com> References: <20230731074829.79309-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.113.25] 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-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772923058930469245 X-GMAIL-MSGID: 1772923058930469245 |
Series |
mm: mremap: fix move page tables
|
|
Commit Message
Kefeng Wang
July 31, 2023, 7:48 a.m. UTC
Archs may need to do special things when flushing thp tlb,
so use the more applicable flush_pud_tlb_range() instead of
flush_tlb_range().
Fixes: 2c91bd4a4e2e ("mm: speed up mremap by 20x on large regions")
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
mm/mremap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Mon, Jul 31, 2023 at 03:48:27PM +0800, Kefeng Wang wrote: > Archs may need to do special things when flushing thp tlb, > so use the more applicable flush_pud_tlb_range() instead of > flush_tlb_range(). > > Fixes: 2c91bd4a4e2e ("mm: speed up mremap by 20x on large regions") > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > --- > mm/mremap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/mremap.c b/mm/mremap.c > index 11e06e4ab33b..1883205fa22b 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -284,7 +284,7 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr, > VM_BUG_ON(!pmd_none(*new_pmd)); > > pmd_populate(mm, new_pmd, pmd_pgtable(pmd)); > - flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE); > + flush_pmd_tlb_range(vma, old_addr, old_addr + PMD_SIZE); I don't think that's correct for arm64. The assumption in the flush_p*d_tlb_range() was that they are called only for block mappings at that p*d level (and we use FEAT_TTL on arm64 indicating that the leaf level is level 2 for pmd, 1 for pud). IIUC move_normal_pmd() is only called for table pmds which would have a leaf level of 3 (the pte). Same for the next patch doing the equivalent for the pud.
On 2023/7/31 19:05, Catalin Marinas wrote: > On Mon, Jul 31, 2023 at 03:48:27PM +0800, Kefeng Wang wrote: >> Archs may need to do special things when flushing thp tlb, >> so use the more applicable flush_pud_tlb_range() instead of >> flush_tlb_range(). >> >> Fixes: 2c91bd4a4e2e ("mm: speed up mremap by 20x on large regions") >> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> >> --- >> mm/mremap.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/mremap.c b/mm/mremap.c >> index 11e06e4ab33b..1883205fa22b 100644 >> --- a/mm/mremap.c >> +++ b/mm/mremap.c >> @@ -284,7 +284,7 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr, >> VM_BUG_ON(!pmd_none(*new_pmd)); >> >> pmd_populate(mm, new_pmd, pmd_pgtable(pmd)); >> - flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE); >> + flush_pmd_tlb_range(vma, old_addr, old_addr + PMD_SIZE); > > I don't think that's correct for arm64. The assumption in the > flush_p*d_tlb_range() was that they are called only for block mappings > at that p*d level (and we use FEAT_TTL on arm64 indicating that the leaf > level is level 2 for pmd, 1 for pud). IIUC move_normal_pmd() is only > called for table pmds which would have a leaf level of 3 (the pte). oops, yes, this is for NORMAL_PMD case, not HPAGE_PMD, please ignore patch 2/3. > > Same for the next patch doing the equivalent for the pud. >
Hi Kefeng,
kernel test robot noticed the following build errors:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on arm-perf/for-next/perf linus/master v6.5-rc4 next-20230731]
[cannot apply to akpm-mm/mm-everything]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Kefeng-Wang/mm-hugetlb-use-flush_hugetlb_tlb_range-in-move_hugetlb_page_tables/20230731-154016
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
patch link: https://lore.kernel.org/r/20230731074829.79309-3-wangkefeng.wang%40huawei.com
patch subject: [PATCH 2/4] mm: mremap: use flush_pmd_tlb_range() in move_normal_pmd()
config: x86_64-defconfig (https://download.01.org/0day-ci/archive/20230731/202307312137.ormxuS5g-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce: (https://download.01.org/0day-ci/archive/20230731/202307312137.ormxuS5g-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202307312137.ormxuS5g-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from <command-line>:
In function 'move_normal_pmd',
inlined from 'move_pgt_entry' at mm/mremap.c:463:11,
inlined from 'move_page_tables' at mm/mremap.c:565:8:
>> include/linux/compiler_types.h:397:45: error: call to '__compiletime_assert_338' declared with attribute error: BUILD_BUG failed
397 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler_types.h:378:25: note: in definition of macro '__compiletime_assert'
378 | prefix ## suffix(); \
| ^~~~~~
include/linux/compiler_types.h:397:9: note: in expansion of macro '_compiletime_assert'
397 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:59:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
| ^~~~~~~~~~~~~~~~
include/linux/pgtable.h:1415:49: note: in expansion of macro 'BUILD_BUG'
1415 | #define flush_pmd_tlb_range(vma, addr, end) BUILD_BUG()
| ^~~~~~~~~
mm/mremap.c:287:9: note: in expansion of macro 'flush_pmd_tlb_range'
287 | flush_pmd_tlb_range(vma, old_addr, old_addr + PMD_SIZE);
| ^~~~~~~~~~~~~~~~~~~
vim +/__compiletime_assert_338 +397 include/linux/compiler_types.h
eb5c2d4b45e3d2 Will Deacon 2020-07-21 383
eb5c2d4b45e3d2 Will Deacon 2020-07-21 384 #define _compiletime_assert(condition, msg, prefix, suffix) \
eb5c2d4b45e3d2 Will Deacon 2020-07-21 385 __compiletime_assert(condition, msg, prefix, suffix)
eb5c2d4b45e3d2 Will Deacon 2020-07-21 386
eb5c2d4b45e3d2 Will Deacon 2020-07-21 387 /**
eb5c2d4b45e3d2 Will Deacon 2020-07-21 388 * compiletime_assert - break build and emit msg if condition is false
eb5c2d4b45e3d2 Will Deacon 2020-07-21 389 * @condition: a compile-time constant condition to check
eb5c2d4b45e3d2 Will Deacon 2020-07-21 390 * @msg: a message to emit if condition is false
eb5c2d4b45e3d2 Will Deacon 2020-07-21 391 *
eb5c2d4b45e3d2 Will Deacon 2020-07-21 392 * In tradition of POSIX assert, this macro will break the build if the
eb5c2d4b45e3d2 Will Deacon 2020-07-21 393 * supplied condition is *false*, emitting the supplied error message if the
eb5c2d4b45e3d2 Will Deacon 2020-07-21 394 * compiler has support to do so.
eb5c2d4b45e3d2 Will Deacon 2020-07-21 395 */
eb5c2d4b45e3d2 Will Deacon 2020-07-21 396 #define compiletime_assert(condition, msg) \
eb5c2d4b45e3d2 Will Deacon 2020-07-21 @397 _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
eb5c2d4b45e3d2 Will Deacon 2020-07-21 398
Hi Kefeng,
kernel test robot noticed the following build errors:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on arm-perf/for-next/perf linus/master v6.5-rc4]
[cannot apply to akpm-mm/mm-everything]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Kefeng-Wang/mm-hugetlb-use-flush_hugetlb_tlb_range-in-move_hugetlb_page_tables/20230731-154016
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
patch link: https://lore.kernel.org/r/20230731074829.79309-3-wangkefeng.wang%40huawei.com
patch subject: [PATCH 2/4] mm: mremap: use flush_pmd_tlb_range() in move_normal_pmd()
config: x86_64-randconfig-x003-20230731 (https://download.01.org/0day-ci/archive/20230801/202308010553.KxefZFdO-lkp@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce: (https://download.01.org/0day-ci/archive/20230801/202308010553.KxefZFdO-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202308010553.KxefZFdO-lkp@intel.com/
All errors (new ones prefixed by >>):
>> ld.lld: error: call to __compiletime_assert_860 marked "dontcall-error": BUILD_BUG failed
diff --git a/mm/mremap.c b/mm/mremap.c index 11e06e4ab33b..1883205fa22b 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -284,7 +284,7 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr, VM_BUG_ON(!pmd_none(*new_pmd)); pmd_populate(mm, new_pmd, pmd_pgtable(pmd)); - flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE); + flush_pmd_tlb_range(vma, old_addr, old_addr + PMD_SIZE); if (new_ptl != old_ptl) spin_unlock(new_ptl); spin_unlock(old_ptl);