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 647EFC433EF for ; Mon, 27 Dec 2021 01:44:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 687746B0071; Sun, 26 Dec 2021 20:44:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 636856B0072; Sun, 26 Dec 2021 20:44:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D73D6B0073; Sun, 26 Dec 2021 20:44:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id 3C3596B0071 for ; Sun, 26 Dec 2021 20:44:51 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D0AA9180C851F for ; Mon, 27 Dec 2021 01:44:50 +0000 (UTC) X-FDA: 78961880340.15.E214538 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf23.hostedemail.com (Postfix) with ESMTP id BF2E514000E for ; Mon, 27 Dec 2021 01:44:40 +0000 (UTC) Received: from dggpemm500023.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4JMgQM26Kvz8w5B; Mon, 27 Dec 2021 09:42:19 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggpemm500023.china.huawei.com (7.185.36.83) 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 09:44:25 +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.20; Mon, 27 Dec 2021 09:44:24 +0800 Message-ID: Date: Mon, 27 Dec 2021 09:44:24 +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 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior Content-Language: en-US To: Christophe Leroy , Jonathan Corbet , Andrew Morton , "linuxppc-dev@lists.ozlabs.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "x86@kernel.org" , "linux-arm-kernel@lists.infradead.org" CC: Catalin Marinas , Dave Hansen , Nicholas Piggin , "Ingo Molnar" , Borislav Petkov , "H. Peter Anvin" , Paul Mackerras , Thomas Gleixner , Will Deacon References: <20211226083912.166512-1-wangkefeng.wang@huawei.com> <20211226083912.166512-2-wangkefeng.wang@huawei.com> <6c4bd989-268e-5899-09a7-ac573bd8b4d9@csgroup.eu> From: Kefeng Wang In-Reply-To: <6c4bd989-268e-5899-09a7-ac573bd8b4d9@csgroup.eu> Content-Type: text/plain; charset="UTF-8"; format=flowed X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggeme704-chm.china.huawei.com (10.1.199.100) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: BF2E514000E X-Stat-Signature: 5bmag18ww5abwbccczd8kqo9bbgkecbo Authentication-Results: imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-HE-Tag: 1640569480-324939 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 2021/12/27 1:36, Christophe Leroy wrote: > > Le 26/12/2021 =C3=A0 09:39, Kefeng Wang a =C3=A9crit=C2=A0: >> Add HUGE_VMALLOC_DEFAULT_ENABLED to let user to choose whether or >> not enable huge vmalloc mappings by default, and this could make >> more architectures to enable huge vmalloc mappings feature but >> don't want to enable it by default. >> >> Add hugevmalloc=3Don/off parameter to enable or disable this feature >> at boot time, nohugevmalloc is still supported and equivalent to >> hugevmalloc=3Doff. > > Is there a real added value to have the user be able to select that ? > > If the architecture supports it, is there any good reason to not use it= ? There are some disadvantages[1],=C2=A0 one of the main concerns is the po= ssible memory waste, we have backported this feature to our kernel 5.10, but our downstream in our some scenario(especially in embedded), they don't want it enabled by default, and others want it, this is why patch1 comes. > > Why not just do like PPC and enable it by default ? Why should it be > enabled by default on PPC but disabled by default on ARM64 and X86 ? The PPC is default enabled, we don't changes this behavior. Maybe upstream is not care about this, as I said in cover-letter, if=20 arm64/x86 don't want patch1, we could only just select config to enable it. Let's wait for more feedback. Thanks. [1]=20 https://lore.kernel.org/linux-mm/1616036421.amjz2efujj.astroid@bobo.none/