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 90CF7C6FD1D for ; Thu, 23 Mar 2023 10:15:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32D246B007D; Thu, 23 Mar 2023 06:15:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DDA96B007E; Thu, 23 Mar 2023 06:15:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A5D36B0080; Thu, 23 Mar 2023 06:15:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0C91A6B007D for ; Thu, 23 Mar 2023 06:15:47 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E22C31C56CE for ; Thu, 23 Mar 2023 10:15:46 +0000 (UTC) X-FDA: 80599756692.23.2D1AF32 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf16.hostedemail.com (Postfix) with ESMTP id 27919180016 for ; Thu, 23 Mar 2023 10:15:43 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf16.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679566544; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iXKt+u0jjKo3fXkRF1H3e0YXpFOSMiO0NwnvMMSHkRs=; b=KsrK2wY024u8csmIzbzDvWGFlG8HRa/KlPj8Y9ZmqLTtSnRvqM6rGhFw7ds7cCMgiVwtkj B7XGJhaV40j0CPqndoekkWrrVR+1wiB3Va93ILfP0hExO1HAU9PF5WgD/sSWp4HBE5f7ti DRvtBfd2NAnSaC9cCfnefl9cIXvvN7Y= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf16.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679566544; a=rsa-sha256; cv=none; b=A0xBN0MB9ssQ90pQIrFNaizBZiep3BON/T6LvinbkcGHkfcjRAF3bNHMrpVGSBFOqo2tnt pIy/l0K0RAhK2O7NFCd4vfwaJHR2hvb79YZg3g2lD9DTFdBcXYQyBzMzSHdeefvDZ+S/e1 9cgM+k815GeB6KS4JyYSUoCBOmrpJv0= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 93C88B81EBF; Thu, 23 Mar 2023 10:15:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B040BC4339C; Thu, 23 Mar 2023 10:15:36 +0000 (UTC) Date: Thu, 23 Mar 2023 10:15:33 +0000 From: Catalin Marinas To: Mike Rapoport Cc: Andrew Morton , Arnd Bergmann , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Geert Uytterhoeven , Guo Ren , John Paul Adrian Glaubitz , "Kirill A. Shutemov" , Max Filippov , Michael Ellerman , Rich Felker , Russell King , Will Deacon , Yoshinori Sato , Zi Yan , linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mm@kvack.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org Subject: Re: [PATCH 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Message-ID: References: <20230323092156.2545741-1-rppt@kernel.org> <20230323092156.2545741-3-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230323092156.2545741-3-rppt@kernel.org> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 27919180016 X-Rspam-User: X-Stat-Signature: madfbwmj8zkrd1pjceqcqcz4sbgzybk6 X-HE-Tag: 1679566543-419006 X-HE-Meta: U2FsdGVkX1/x9SJvtWzo3V/6+F+dEpg1pTPheoV1bd4ZgB/zysFDmiIAJAdrBGSEivhS0YQ3JikUaKHJoGePaSIRvmxEOdzM7dYOOqJX1wuQO5A0VhI9i+ON6LLbD9P7bdpENrJCNfjShpT9J68aWLzYHvFWuEO8pd3m3rU2zy8wwQvXekMBa3JUkNvBTtcNFdaa7IuWLE59Tnaiw1KyXYyf9g3BiQ5Kis+1PcrhN3M6GFSK4mydheZhLxJXquKcldW++wdAFveJp5lWtn7BmSCIs7cM8oEA28Y/BLzu9dkMErX8RI84s0s+vmA+PKynO39l/Mq7Py8xkeXnOmUICGJMQd0LL3CKlzw+y+5fRyx0Hw8jkwHLDYbJi1alTgt9baWIMz1V20VWfKahXKWYLXqvNA8YgaMWtbQgjMkmB8wxvJSfpMBSjDLwtgRMpcfQYQNT3Ds4lPk4O57/QiWPT8MK4P0IlHRDb67REs5O2tAa/mLUhACce9qH0/tji8z+q9Nlo+pzrykBoqhnYoBe4S74VVTTlRL2GBiJPlc8MULhSTcXCwoOSjSsPUfybiTx/0nsbBbaQvgaCtGbMD4pj8BHhgGXjAOH3uCkt2eTO8y/c3n3H9pj5u9mhEZh2+1/mk36jJrHnEgduxBg8hA8zbLBAoi8oqDF6I941vFKvaLOtZCxsL/OGw02nWy4DTXUjOFukJU5Ud2nn0D7W8R/4JB3cQf4zE/uRpMgmEBZU9+rCUmWMGXwCKPaPqL7VFpL94WNiEom9oalxoarT+qmQS3zwwKPcW1Kj4mgYmBvtI5iMovBulA2azibyG3SfirigoupI8yJ9V0bZSkIimLrm97PdsNr/Cz6Gaet4FWqn6w7iSjdFf9BNRYsG7JRMDJXk7MFu33B9y/Sovu6oTriNcEaBx0RL29XLitlHrFZamTF0XLi6AFtgyMWOJHPmnvZKiLckDnJIPuoCVkTQuN t3oS/SYv QTKPMbNh2pf80eQwE1G3Pc23Qhg7qMmT3Y9YZ/lqfSY+IjPRzfv2LTbg/agVwhvYtJ3twG5xVBnax7eb0TstEUMe+4EbyUUPpoOG9okmZAo10iIs2Zh6Bz3SiMMeGe41K2PHIPedDpo//GzDF/J75XfwZ9jyw5EICbHKVbM1VTVw5lc+oq9eJeXCLpd23OgW3XW4feZDzStnQyOjss7/+WctIPQjvmMHkw5DsJCg3oRcxHc+QVP8f8JaACtUP6kUXGptZSukch5Kj5rhapDDY1Ov/f3rxkZ0SQK83LK0SbrXn391lmY5q/p0GLOJdRmQqFku1PrA0qrT6ICqLosLQEPNU1PxJopSxV8BNvLhQqBeAk7sjX5mUhgaewE3UfyKvRNGhrscaKMt3F/h9A9PNeIwgevFHzXpfLi5E 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 Thu, Mar 23, 2023 at 11:21:44AM +0200, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > It is not a good idea to change fundamental parameters of core memory > management. Having predefined ranges suggests that the values within > those ranges are sensible, but one has to *really* understand > implications of changing MAX_ORDER before actually amending it and > ranges don't help here. > > Drop ranges in definition of ARCH_FORCE_MAX_ORDER > > Signed-off-by: Mike Rapoport (IBM) > --- > arch/arm64/Kconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index e60baf7859d1..bab6483e4317 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1489,9 +1489,7 @@ config XEN > config ARCH_FORCE_MAX_ORDER > int "Maximum zone order" if ARM64_4K_PAGES || ARM64_16K_PAGES > default "13" if ARM64_64K_PAGES > - range 11 13 if ARM64_16K_PAGES > default "11" if ARM64_16K_PAGES > - range 10 15 if ARM64_4K_PAGES > default "10" I don't mind rewriting the help text as in the subsequent patch but I'd keep the ranges as a safety measure. It's less wasted time explaining to people why some random max order doesn't work. Alternatively, we can drop the ranges but make this option configurable only if EXPERT. -- Catalin