Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp101794rwr; Wed, 19 Apr 2023 04:08:24 -0700 (PDT) X-Google-Smtp-Source: AKy350Z7RauHyQ0PUtkLERAYamcNPj18hF06HP1ruESsIh+Z7L4X9NocM1ILafbFbT2NwUNoNCxH X-Received: by 2002:a17:90a:b78e:b0:247:4c28:311f with SMTP id m14-20020a17090ab78e00b002474c28311fmr2443344pjr.34.1681902504633; Wed, 19 Apr 2023 04:08:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681902504; cv=none; d=google.com; s=arc-20160816; b=ejvGVzKUMfSu0mYbZQfEOD5akKZp1znRYGzy1yL2pqn/lVc4Sh3VCkntf7rSgZC2vs 5Kix89YucG0/2nEmmOLUpboQikQI+GY/CuZjt+y/WvqUmofeI01jm2SL4UEL8kpUE1X1 uVoXoOWLFKTp4fkharNTPa5CkkKms9+NsGQ1EIEMSSTwjGzZ6aHEZ49eY4rbVxznQM9W 6nJf+FJhE0zHsUI25I7E1IFXHzwDMlborNPQNqgHeWoC91LPLNpiSd9FtLan4RN8JT8D 2xnq6MUxM+qFsNHQ1uekpcI+7yvNWnpCHiuunm3pt+5x6pfzDngD1rLtj6mK8Z/pmKpn mR0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Yh7nm9G6tXNKNhn1qv/ac7gRo2SwzJ3+YuDLIEM5lrE=; b=Lk8IwasghjZMzP6GVUay5ap4oIugsCIAVubssI0wtXfRh8omdyC+EgeBa+8NFmQ6Pn 27uqrZ0uPdFFMRQTv8fQtucjzBCJSZ+3ZtNG7zYJLbUASUodq1RaFMrD5xYv+MPuWVW5 tLaKEsR4tc9JFXfTRZKuGSneFBTGB7VDW9ijZ2Uz49Wnj4SUgA1ENwJNCKeAzWHYfC5N dBkXz+WD4ut+C2tSGEt9wyLIreqoHSG4OaGRwSwIpSDzA++7/DQTqA5K+85h0aFYR31C +394ZLV2Wn7l8ADnBH73NZup1r77B1DXCFea1fVgH86dQveaZjsHRJYczhsOkRFlP0O5 /6YQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x5-20020a17090a1f8500b0024681cc291csi1576493pja.88.2023.04.19.04.08.13; Wed, 19 Apr 2023 04:08:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232505AbjDSLFm (ORCPT + 99 others); Wed, 19 Apr 2023 07:05:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231527AbjDSLFi (ORCPT ); Wed, 19 Apr 2023 07:05:38 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B6A24C19; Wed, 19 Apr 2023 04:05:37 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id C896963D4C; Wed, 19 Apr 2023 11:05:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C58FEC433EF; Wed, 19 Apr 2023 11:05:31 +0000 (UTC) Date: Wed, 19 Apr 2023 12:05:28 +0100 From: Catalin Marinas To: Andrew Morton Cc: Justin Forbes , Mike Rapoport , 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 v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Message-ID: References: <20230325060828.2662773-1-rppt@kernel.org> <20230325060828.2662773-3-rppt@kernel.org> <20230418150557.ea8c87c96ec64c899c88ab08@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230418150557.ea8c87c96ec64c899c88ab08@linux-foundation.org> X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 18, 2023 at 03:05:57PM -0700, Andrew Morton wrote: > On Wed, 12 Apr 2023 18:27:08 +0100 Catalin Marinas wrote: > > > It sounds nice in theory. In practice. EXPERT hides too much. When you > > > flip expert, you expose over a 175ish new config options which are > > > hidden behind EXPERT. You don't have to know what you are doing just > > > with the MAX_ORDER, but a whole bunch more as well. If everyone were > > > already running 10, this might be less of a problem. At least Fedora > > > and RHEL are running 13 for 4K pages on aarch64. This was not some > > > accidental choice, we had to carry a patch to even allow it for a > > > while. If this does go in as is, we will likely just carry a patch to > > > remove the "if EXPERT", but that is a bit of a disservice to users who > > > might be trying to debug something else upstream, bisecting upstream > > > kernels or testing a patch. In those cases, people tend to use > > > pristine upstream sources without distro patches to verify, and they > > > tend to use their existing configs. With this change, their MAX_ORDER > > > will drop to 10 from 13 silently. That can look like a different > > > issue enough to ruin a bisect or have them give bad feedback on a > > > patch because it introduces a "regression" which is not a regression > > > at all, but a config change they couldn't see. > > > > If we remove EXPERT (as prior to this patch), I'd rather keep the ranges > > and avoid having to explain to people why some random MAX_ORDER doesn't > > build (keeping the range would also make sense for randconfig, not sure > > we got to any conclusion there). > > Well this doesn't seem to have got anywhere. I think I'll send the > patchset into Linus for the next merge window as-is. Please let's take > a look at this Kconfig presentation issue during the following -rc > cycle. That's fine by me. I have a slight preference to drop EXPERT and keep the ranges in, especially if it affects current distro kernels. Debian seems to enable EXPERT already in their arm64 kernel config but I'm not sure about the Fedora or other distro kernels. If they don't, we can fix/revert this Kconfig entry once the merging window is closed. -- Catalin