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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 365C8C433F5 for ; Wed, 19 Jan 2022 13:44:56 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Jf6MV2zvYz3bc4 for ; Thu, 20 Jan 2022 00:44:54 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=huawei.com (client-ip=45.249.212.189; helo=szxga03-in.huawei.com; envelope-from=wangkefeng.wang@huawei.com; receiver=) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) (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 4Jf6M23nJTz2xv0 for ; Thu, 20 Jan 2022 00:44:27 +1100 (AEDT) Received: from dggpemm500023.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Jf6Hb6hngz8wNx; Wed, 19 Jan 2022 21:41:31 +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.21; Wed, 19 Jan 2022 21:44:21 +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 21:44:21 +0800 Message-ID: <93db576e-9a62-ee98-5af2-a62f8386212c@huawei.com> Date: Wed, 19 Jan 2022 21:44:20 +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: 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: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggeme702-chm.china.huawei.com (10.1.199.98) 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: x86@kernel.org, "H. Peter Anvin" , Dave Hansen , linux-doc@vger.kernel.org, Jonathan Corbet , linux-kernel@vger.kernel.org, Nicholas Piggin , linux-mm@kvack.org, Will Deacon , Ingo Molnar , Borislav Petkov , Catalin Marinas , Paul Mackerras , Andrew Morton , linuxppc-dev@lists.ozlabs.org, Thomas Gleixner , linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 2022/1/19 21:22, Matthew Wilcox wrote: > On Wed, Jan 19, 2022 at 08:57:58PM +0800, Kefeng Wang wrote: >> Only parts of our products wants this feature,  we add some interfaces which >> only >> >> alloc hugevmalloc for them, eg, >> vmap_hugepage/vmalloc_hugepage/remap_vmalloc_hugepage_range.. >> >> for our products, but it's not the choice of most products, also add >> nohugevmalloc >> >> for most products is expensive, so this is the reason for adding the patch. >> >> more config/cmdline are more flexible for test/products， > But why do only some products want it? What goes wrong if all products > enable it? Features should be auto-tuning, not relying on admins to > understand them. Because this feature will use more memory for vmalloc/vmap, that's why we add some explicit interfaces as said above in our kernel to control the user.