All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Justin Forbes <jforbes@fedoraproject.org>,
	Catalin Marinas <catalin.marinas@arm.com>
Cc: Mike Rapoport <rppt@kernel.org>, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, jmforbes@linuxtx.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] Revert arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
Date: Tue, 02 May 2023 15:21:17 +0100	[thread overview]
Message-ID: <86pm7ihl0i.wl-maz@kernel.org> (raw)
In-Reply-To: <ZFEZLZHBosQK9xaH@arm.com>

On Tue, 02 May 2023 15:07:41 +0100,
Catalin Marinas <catalin.marinas@arm.com> wrote:
> 
> On Mon, May 01, 2023 at 04:24:38PM -0500, Justin Forbes wrote:
> > On Sat, Apr 29, 2023 at 11:02 PM Mike Rapoport <rppt@kernel.org> wrote:
> > > Why the default MAX_ORDER was not acceptable on arm64 server machines but
> > > it is fine on, say, x86 and s390?
> > > I'm not asking how you made it possible in Fedora and RHEL, I'm asking why
> > > did you switch from the default order at all.
> > 
> > Because the MAX_ORDER on aarch64 with 4K pages is more tuned to the
> > needs of the average edge client, not so much those of a server class
> > machine.  And I get it, I would say well over 90% of the Fedora users
> > running aarch64 are indeed running on a rPi or similar with a small
> > memory footprint, and workloads which match that.  But we do support
> > and run a 4K page size aarch64 kernel on proper server class hardware,
> > running typical server workloads, and RHEL has a lot more users in the
> > server class than edge clients.   RHEL could probably default to 64K
> > pages, and most users would be happy with that. Fedora certainly could
> > not. 
> 
> I was talking to Marc Zyngier earlier and he reckons the need for a
> higher MAX_ORDER is the GIC driver ITS allocation for Thunder-X. I'm
> happy to make ARCH_MAX_ORDER higher in defconfig (12, 13?) if
> CONFIG_ARCH_THUNDER. Mobile vendors won't enable this platform.

In any case, I'd like to know exactly *what* requires it. The only
platform I know would benefit from this is the old TX1, but this
machine is more a boat anchor than a real server.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Justin Forbes <jforbes@fedoraproject.org>,
	Catalin Marinas <catalin.marinas@arm.com>
Cc: Mike Rapoport <rppt@kernel.org>, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, jmforbes@linuxtx.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] Revert arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
Date: Tue, 02 May 2023 15:21:17 +0100	[thread overview]
Message-ID: <86pm7ihl0i.wl-maz@kernel.org> (raw)
In-Reply-To: <ZFEZLZHBosQK9xaH@arm.com>

On Tue, 02 May 2023 15:07:41 +0100,
Catalin Marinas <catalin.marinas@arm.com> wrote:
> 
> On Mon, May 01, 2023 at 04:24:38PM -0500, Justin Forbes wrote:
> > On Sat, Apr 29, 2023 at 11:02 PM Mike Rapoport <rppt@kernel.org> wrote:
> > > Why the default MAX_ORDER was not acceptable on arm64 server machines but
> > > it is fine on, say, x86 and s390?
> > > I'm not asking how you made it possible in Fedora and RHEL, I'm asking why
> > > did you switch from the default order at all.
> > 
> > Because the MAX_ORDER on aarch64 with 4K pages is more tuned to the
> > needs of the average edge client, not so much those of a server class
> > machine.  And I get it, I would say well over 90% of the Fedora users
> > running aarch64 are indeed running on a rPi or similar with a small
> > memory footprint, and workloads which match that.  But we do support
> > and run a 4K page size aarch64 kernel on proper server class hardware,
> > running typical server workloads, and RHEL has a lot more users in the
> > server class than edge clients.   RHEL could probably default to 64K
> > pages, and most users would be happy with that. Fedora certainly could
> > not. 
> 
> I was talking to Marc Zyngier earlier and he reckons the need for a
> higher MAX_ORDER is the GIC driver ITS allocation for Thunder-X. I'm
> happy to make ARCH_MAX_ORDER higher in defconfig (12, 13?) if
> CONFIG_ARCH_THUNDER. Mobile vendors won't enable this platform.

In any case, I'd like to know exactly *what* requires it. The only
platform I know would benefit from this is the old TX1, but this
machine is more a boat anchor than a real server.

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2023-05-02 14:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-28 15:36 [PATCH] Revert arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Justin M. Forbes
2023-04-28 15:36 ` Justin M. Forbes
2023-04-28 17:01 ` Catalin Marinas
2023-04-28 17:01   ` Catalin Marinas
2023-04-29 19:01   ` Mike Rapoport
2023-04-29 19:01     ` Mike Rapoport
2023-04-29 22:42     ` Justin Forbes
2023-04-29 22:42       ` Justin Forbes
2023-04-30  3:54       ` Mike Rapoport
2023-04-30  3:54         ` Mike Rapoport
2023-05-01 21:24         ` Justin Forbes
2023-05-01 21:24           ` Justin Forbes
2023-05-02 14:07           ` Catalin Marinas
2023-05-02 14:07             ` Catalin Marinas
2023-05-02 14:21             ` Marc Zyngier [this message]
2023-05-02 14:21               ` Marc Zyngier
2023-05-02 16:12               ` Mike Rapoport
2023-05-02 16:12                 ` Mike Rapoport
2023-05-02 16:15             ` Mike Rapoport
2023-05-02 16:15               ` Mike Rapoport
2023-05-02 17:40               ` Catalin Marinas
2023-05-02 17:40                 ` Catalin Marinas
2023-05-03 10:20                 ` Catalin Marinas
2023-05-03 10:20                   ` Catalin Marinas
2023-05-03 12:08                   ` Philip Li
2023-05-03 12:08                     ` Philip Li

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=86pm7ihl0i.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=jforbes@fedoraproject.org \
    --cc=jmforbes@linuxtx.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rppt@kernel.org \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.