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

[Mike Rapoport]

On Sat, May 06, 2023 at 12:51:52AM +0200, Ard Biesheuvel wrote:
> 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?

Well, that's up to Fedora/RHEL to drop their changes to the configuration.
Since Kirill's changes to MAX_ORDER semantics they will have to update
their config anyway for 6.4 and onwards.

-- 
Sincerely yours,
Mike.