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 18C29C433EF for ; Wed, 19 Jan 2022 12:58:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C2086B0071; Wed, 19 Jan 2022 07:58:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 370156B0073; Wed, 19 Jan 2022 07:58:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25F566B0074; Wed, 19 Jan 2022 07:58:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0047.hostedemail.com [216.40.44.47]) by kanga.kvack.org (Postfix) with ESMTP id 133676B0071 for ; Wed, 19 Jan 2022 07:58:05 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C309F181CC1D0 for ; Wed, 19 Jan 2022 12:58:04 +0000 (UTC) X-FDA: 79047039288.24.D2CD9DC Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf29.hostedemail.com (Postfix) with ESMTP id 9A20712000C for ; Wed, 19 Jan 2022 12:58:03 +0000 (UTC) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Jf5Hx5S6gz9s5T; Wed, 19 Jan 2022 20:56:45 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 19 Jan 2022 20:57:59 +0800 Received: from [10.174.177.243] (10.174.177.243) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.21; Wed, 19 Jan 2022 20:57:58 +0800 Message-ID: Date: Wed, 19 Jan 2022 20:57:58 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior Content-Language: en-US To: Nicholas Piggin , Andrew Morton , Jonathan Corbet , , , , , , CC: Benjamin Herrenschmidt , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , "H. Peter Anvin" , Ingo Molnar , "Michael Ellerman" , Paul Mackerras , "Thomas Gleixner" , Will Deacon , Matthew Wilcox References: <20211227145903.187152-1-wangkefeng.wang@huawei.com> <20211227145903.187152-2-wangkefeng.wang@huawei.com> <1642473992.qrnqczjfna.astroid@bobo.none> From: Kefeng Wang In-Reply-To: <1642473992.qrnqczjfna.astroid@bobo.none> Content-Type: text/plain; charset="UTF-8"; format=flowed X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggeme714-chm.china.huawei.com (10.1.199.110) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 9A20712000C X-Stat-Signature: 59pwdk7ngw3s6w5whyqohpaequ46xpnx Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf29.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com X-HE-Tag: 1642597083-757449 Content-Transfer-Encoding: quoted-printable 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 2022/1/18 10:52, Nicholas Piggin wrote: > Excerpts from Kefeng Wang's message of December 28, 2021 12:59 am: >> Introduce HUGE_VMALLOC_DEFAULT_ENABLED and make it default y, this >> let user to choose whether or not enable huge vmalloc mappings by >> default. >> >> Meanwhile, add new hugevmalloc=3Don/off parameter to enable or disable >> this feature at boot time, nohugevmalloc is still supported and >> equivalent to hugevmalloc=3Doff. > Runtime options are bad enough, Kconfig and boot options are even worse= . nohugevmalloc is like blacklists, on the other hand, Add a=20 HUGE_VMALLOC_DEFAULT_ENABLED to close hugevmalloc default and enable it only via hugevmalloc=3Don is=20 whiteList. Only parts of our products wants this feature,=C2=A0 we add some interfac= es=20 which only alloc hugevmalloc for them, eg,=20 vmap_hugepage/vmalloc_hugepage/remap_vmalloc_hugepage_range.. for our products, but it's not the choice of most products, also add=20 nohugevmalloc for most products is expensive, so this is the reason for adding the patc= h. more config/cmdline are more flexible for test/products=EF=BC=8C > > The 'nohugevmalloc' option mirrors 'nohugeiomap' and is not expected to > ever be understood by an administrator unless a kernel developer is > working with them to hunt down a regression. > > IMO there should be no new options. You could switch it off for > CONFIG_BASE_SMALL perhaps, and otherwise just try to work on heuristics > first. Bring in new options once it's proven they're needed. but yes, this patch is optional=EF=BC=8C could others give some more comm= ents=20 about this way=EF=BC=9F Thanks. > Aside from that, thanks for working on these ports, great work. > > Thanks, > Nick > .