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: 1573383 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org (client-ip=2404:9400:2:0:216:3eff:fee1:b9f1; helo=lists.ozlabs.org; envelope-from=linuxppc-dev-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org; receiver=) Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2404:9400:2:0:216:3eff:fee1:b9f1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4JN0vJ32xFz9sRN for ; Tue, 28 Dec 2021 01:50:03 +1100 (AEDT) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4JN0vH08V3z2ynM for ; Tue, 28 Dec 2021 01:50:03 +1100 (AEDT) X-Original-To: linuxppc-dev@lists.ozlabs.org Delivered-To: linuxppc-dev@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=huawei.com (client-ip=45.249.212.255; helo=szxga08-in.huawei.com; envelope-from=wangkefeng.wang@huawei.com; receiver=) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4JN0v54vJXz2xDT for ; Tue, 28 Dec 2021 01:49:50 +1100 (AEDT) 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 , , , , , , 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-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kefeng Wang , Matthew Wilcox , Catalin Marinas , Dave Hansen , Nicholas Piggin , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Paul Mackerras , Thomas Gleixner , Will Deacon Errors-To: linuxppc-dev-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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(-)