From: Justin Forbes <jforbes@fedoraproject.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"David S. Miller" <davem@davemloft.net>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Guo Ren <guoren@kernel.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Rich Felker <dalias@libc.org>,
Russell King <linux@armlinux.org.uk>,
Will Deacon <will@kernel.org>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Zi Yan <ziy@nvidia.com>,
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 v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
Date: Wed, 29 Mar 2023 15:55:37 +0000 [thread overview]
Message-ID: <CAFxkdAr5C7ggZ+WdvDbsfmwuXujT_z_x3qcUnhnCn-WrAurvgA@mail.gmail.com> (raw)
In-Reply-To: <20230325060828.2662773-3-rppt@kernel.org>
On Sat, Mar 25, 2023 at 1:09 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> From: "Mike Rapoport (IBM)" <rppt@kernel.org>
>
> 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 and make its prompt
> visible only if EXPERT=y
I do not like suddenly hiding this behind EXPERT for a couple of
reasons. Most importantly, it will silently change the config for
users building with an old kernel config. If a user has for instance
"13" set and building with 4K pages, as is the current configuration
for Fedora and RHEL aarch64 builds, an oldconfig build will now set it
to 10 with no indication that it is doing so. And while I think that
10 is a fine default for many aarch64 users, there are valid reasons
for choosing other values. Putting this behind expert makes it much
less obvious that this is an option.
Justin
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> ---
> arch/arm64/Kconfig | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e60baf7859d1..7324032af859 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1487,11 +1487,9 @@ config XEN
> # 16K | 27 | 14 | 13 | 11 |
> # 64K | 29 | 16 | 13 | 13 |
> config ARCH_FORCE_MAX_ORDER
> - int "Maximum zone order" if ARM64_4K_PAGES || ARM64_16K_PAGES
> + int "Maximum zone order" if EXPERT && (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"
> help
> The kernel memory allocator divides physically contiguous memory
> --
> 2.35.1
>
>
next prev parent reply other threads:[~2023-03-29 15:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-25 6:08 [PATCH v3 00/14] arch,mm: cleanup Kconfig entries for ARCH_FORCE_MAX_ORDER Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 01/14] arm: reword ARCH_FORCE_MAX_ORDER prompt and help text Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Mike Rapoport
2023-03-25 6:35 ` Kefeng Wang
2023-03-29 15:55 ` Justin Forbes [this message]
2023-04-04 7:22 ` Mike Rapoport
2023-04-04 11:50 ` Justin Forbes
2023-04-12 17:27 ` Catalin Marinas
2023-04-18 22:05 ` Andrew Morton
2023-04-19 11:05 ` Catalin Marinas
2023-04-19 11:27 ` Justin Forbes
2023-04-25 16:09 ` Justin Forbes
2023-04-27 13:40 ` Catalin Marinas
2023-03-25 6:08 ` [PATCH v3 03/14] arm64: reword ARCH_FORCE_MAX_ORDER prompt and help text Mike Rapoport
2023-03-25 6:35 ` Kefeng Wang
2023-03-25 6:08 ` [PATCH v3 04/14] csky: drop ARCH_FORCE_MAX_ORDER Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 05/14] ia64: don't allow users to override ARCH_FORCE_MAX_ORDER Mike Rapoport
2023-03-25 6:38 ` Kefeng Wang
2023-04-19 8:56 ` Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 06/14] m68k: reword ARCH_FORCE_MAX_ORDER prompt and help text Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 07/14] nios2: " Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 08/14] nios2: drop ranges for definition of ARCH_FORCE_MAX_ORDER Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 09/14] powerpc: reword ARCH_FORCE_MAX_ORDER prompt and help text Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 10/14] powerpc: drop ranges for definition of ARCH_FORCE_MAX_ORDER Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 11/14] sh: reword ARCH_FORCE_MAX_ORDER prompt and help text Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 12/14] sh: drop ranges for definition of ARCH_FORCE_MAX_ORDER Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 13/14] sparc: reword ARCH_FORCE_MAX_ORDER prompt and help text Mike Rapoport
2023-03-25 6:08 ` [PATCH v3 14/14] xtensa: " Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFxkdAr5C7ggZ+WdvDbsfmwuXujT_z_x3qcUnhnCn-WrAurvgA@mail.gmail.com \
--to=jforbes@fedoraproject.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=dalias@libc.org \
--cc=davem@davemloft.net \
--cc=dinguyen@kernel.org \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=guoren@kernel.org \
--cc=jcmvbkbc@gmail.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mm@kvack.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=rppt@kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=will@kernel.org \
--cc=ysato@users.sourceforge.jp \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).