[PATCH] arm64: Make the ARCH_FORCE_MAX_ORDER config input prompt unconditional

[Ard Biesheuvel]

On Sat, 6 May 2023 at 00:47, Mike Rapoport <rppt at kernel.org> wrote:
>
> On Sat, May 06, 2023 at 12:08:33AM +0200, Ard Biesheuvel wrote:
> > On Sat, 6 May 2023 at 00:01, Mike Rapoport <rppt at kernel.org> wrote:
> > >
> > > On Wed, May 03, 2023 at 05:41:19PM +0200, Ard Biesheuvel wrote:
> > > > On Wed, 3 May 2023 at 17:36, Justin Forbes <jforbes at fedoraproject.org> wrote:
> > > > >
> > > > > On Wed, May 3, 2023 at 7:33 AM Catalin Marinas <catalin.marinas at arm.com> wrote:
> > > > > >
> > > > > > Commit 34affcd7577a ("arm64: drop ranges in definition of
> > > > > > ARCH_FORCE_MAX_ORDER") dropped the ranges from the config entry and
> > > > > > introduced an EXPERT condition on the input prompt instead. This change
> > > > > > may affect some distro kernels that change ARCH_FORCE_MAX_ORDER but do
> > > > > > not want to enable EXPERT.
> > > > > >
> > > > > > Drop EXPERT from the input prompt together with the (ARM64_4K_PAGES ||
> > > > > > ARM64_16K_PAGES) condition as the latter no longer makes sense after the
> > > > > > ranges were removed. The latter makes all the page size configurations
> > > > > > consistent w.r.t. ARCH_FORCE_MAX_ORDER.
> > > > > >
> > > > > > Fixes: 34affcd7577a ("arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER")
> > > > > > Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
> > > > > > Reported-by: Justin M. Forbes <jforbes at fedoraproject.org>
> > > > > > Cc: Will Deacon <will at kernel.org>
> > > > > > Cc: Mike Rapoport <rppt at kernel.org>
> > > > > > Cc: Andrew Morton <akpm at linux-foundation.org>
> > > > >
> > > > > This works for me, thanks.
> > > > >
> > > > > Acked-by: Justin M. Forbes <jforbes at fedoraproject.org>
> > > > >
> > > >
> > > > I'd still be interested in gaining a better understanding as to why
> > > > Fedora/RHEL think they need to change this value on arm64. In
> > > > particular, whether it is to support ThunderX, or whether there are
> > > > any good reasons for doing so that we are unaware of.
> > >
> > > Yeah, there still was no explanation why Fedora/RHEL had to increase
> > > MAX_ORDER in their configs.
> > >
> > > I'm surely missing something, but I also don't understand why ThunderX
> > > would need physically contiguous allocations larger than 4M.
> >
> > https://lore.kernel.org/all/1430686172-18222-5-git-send-email-rric@kernel.org/
>
> But does not the second patch in that series (now commit 30f2136346ca
> ("irqchip/gicv3-its: Add range check for number of allocated pages"))
> ensures that allocation is not larger than 256 pages?
>
> Or this is another allocation?
>

I have no idea, but that it not really the point.

The point is that ThunderX is obsolete - it was never a very
compelling value proposition in the first place, but today it is just
a waste of electricity. So if it was the only reason for changing the
max order, perhaps it's time to change it back?