On 23 Mar 2023, at 6:37, Mike Rapoport wrote:
On Thu, Mar 23, 2023 at 10:15:33AM +0000, Catalin Marinas wrote:On Thu, Mar 23, 2023 at 11:21:44AM +0200, Mike Rapoport wrote:From: "Mike Rapoport (IBM)" <rppt@xxxxxxxxxx> 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) <rppt@xxxxxxxxxx> --- 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.I like the EXPERT alternative more. I'll add it in v2.
I got an error report from kernel test robot, which set -1 to ARCH_FORCE_MAX_ORDER via random config generator[1]. Does the EXPERT option prevent kernel test robot from generating such config? Or we should fix random config generator? [1] https://lore.kernel.org/linux-mm/91E887E4-0867-421F-9C75-FB9CFF15C33A@xxxxxxxxxx/ -- Best Regards, Yan, Zi
Attachment:
signature.asc
Description: OpenPGP digital signature
