From patchwork Mon Dec 27 14:59:00 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kefeng Wang X-Patchwork-Id: 12699827 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 715E2C433FE for ; Mon, 27 Dec 2021 14:49:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7A0826B0071; Mon, 27 Dec 2021 09:49:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 77F1C6B0074; Mon, 27 Dec 2021 09:49:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F84B6B0073; Mon, 27 Dec 2021 09:49:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 50D646B0071 for ; Mon, 27 Dec 2021 09:49:47 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E97AC8249980 for ; Mon, 27 Dec 2021 14:49:46 +0000 (UTC) X-FDA: 78963858372.10.446FE1A Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf01.hostedemail.com (Postfix) with ESMTP id 462824002A for ; Mon, 27 Dec 2021 14:49:36 +0000 (UTC) Received: from dggpemm500021.china.huawei.com (unknown [172.30.72.54]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4JN0q60Bskz1DK7x; Mon, 27 Dec 2021 22:46:26 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggpemm500021.china.huawei.com (7.185.36.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 27 Dec 2021 22:49:41 +0800 Received: from localhost.localdomain.localdomain (10.175.113.25) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 27 Dec 2021 22:49:40 +0800 From: Kefeng Wang To: Jonathan Corbet , Andrew Morton , , , , , , CC: Nicholas Piggin , Catalin Marinas , Will Deacon , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Michael Ellerman , "Benjamin Herrenschmidt" , Paul Mackerras , Christophe Leroy , Matthew Wilcox , Kefeng Wang Subject: [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86 Date: Mon, 27 Dec 2021 22:59:00 +0800 Message-ID: <20211227145903.187152-1-wangkefeng.wang@huawei.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 X-Originating-IP: [10.175.113.25] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 462824002A X-Stat-Signature: f6bugp48xpej1bmub37xd9djf9bm7xoy Authentication-Results: imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Rspamd-Server: rspam10 X-HE-Tag: 1640616576-94353 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: Huge vmalloc mappings is supported on PPC[1], but this feature should be not only used on PPC, it could be used on arch support HAVE_ARCH_HUGE_VMAP and PMD sized vmap mappings. this patchset is to enable this feature on arm64/x86. There are some disadvantages about this feature[2], one of the main concerns is the possible memory fragmentation/waste in some scenarios, also archs must ensure that any arch specific vmalloc allocations that require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX) use the VM_NO_HUGE_VMAP flag to inhibit larger mappings. Based on the above considerations, we add the first patch is to let user to control huge vmalloc mapping default behavior. Meanwhile, add new kernel parameter hugevmalloc=on/off to enable/disable this feature at boot time, nohugevmalloc parameter is still supported. The later two patches to enable this feature on arm64/x86, select HAVE_ARCH_HUGE_VMALLOC and mark VM_NO_HUGE_VMAP in arch's module_alloc(). This patchset based on next-20211224. v2: - Default y for HUGE_VMALLOC_DEFAULT_ENABLED, not only select it on PPC - Fix copy/type error - Mark VM_NO_HUGE_VMAP in module_alloc() on arm64/x86 [1] https://lore.kernel.org/linux-mm/20210317062402.533919-1-npiggin@gmail.com/ [2] https://lore.kernel.org/linux-mm/1616036421.amjz2efujj.astroid@bobo.none/ Kefeng Wang (3): mm: vmalloc: Let user to control huge vmalloc default behavior arm64: Support huge vmalloc mappings x86: Support huge vmalloc mappings .../admin-guide/kernel-parameters.txt | 14 +++++++++++++- arch/arm64/Kconfig | 1 + arch/arm64/kernel/module.c | 5 +++-- arch/x86/Kconfig | 1 + arch/x86/kernel/module.c | 4 ++-- mm/Kconfig | 8 ++++++++ mm/vmalloc.c | 18 +++++++++++++++++- 7 files changed, 45 insertions(+), 6 deletions(-)