All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christoph Lameter (Ampere)" <cl@gentwo.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: catalin.marinas@arm.com, Will Deacon <will@kernel.org>,
	 Jonathan.Cameron@huawei.com, Matteo.Carlini@arm.com,
	 Valentin.Schneider@arm.com, akpm@linux-foundation.org,
	 anshuman.khandual@arm.com, Eric Mackay <eric.mackay@oracle.com>,
	 dave.kleikamp@oracle.com, linux-arm-kernel@lists.infradead.org,
	 linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux@armlinux.org.uk,  robin.murphy@arm.com,
	vanshikonda@os.amperecomputing.com,  yang@os.amperecomputing.com
Subject: [PATCH v3] ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512
Date: Wed, 6 Mar 2024 17:45:04 -0800 (PST)	[thread overview]
Message-ID: <37099a57-b655-3b3a-56d0-5f7fbd49d7db@gentwo.org> (raw)

Currently defconfig selects NR_CPUS=256, but some vendors (e.g. Ampere
Computing) are planning to ship systems with 512 CPUs. So that all CPUs on
these systems can be used with defconfig, we'd like to bump NR_CPUS to 512.
Therefore this patch increases the default NR_CPUS from 256 to 512.

As increasing NR_CPUS will increase the size of cpumasks, there's a fear that
this might have a significant impact on stack usage due to code which places
cpumasks on the stack. To mitigate that concern, we can select
CPUMASK_OFFSTACK. As that doesn't seem to be a problem today with
NR_CPUS=256, we only select this when NR_CPUS > 256.

CPUMASK_OFFSTACK configures the cpumasks in the kernel to be
dynamically allocated. This was used in the X86 architecture in the
past to enable support for larger CPU configurations up to 8k cpus.

With that is becomes possible to dynamically size the allocation of
the cpu bitmaps depending on the quantity of processors detected on
bootup. Memory used for cpumasks will increase if the kernel is
run on a machine with more cores.

Further increases may be needed if ARM processor vendors start
supporting more processors. Given the current inflationary trends
in core counts from multiple processor manufacturers this may occur.

There are minor regressions for hackbench. The kernel data size
for 512 cpus is smaller with offstack than with onstack.

Benchmark results using hackbench average over 10 runs of

 	hackbench -s 512 -l 2000 -g 15 -f 25 -P

on Altra 80 Core

Support for 256 CPUs on stack. Baseline

 	7.8564 sec

Support for 512 CUs on stack.

 	7.8713 sec + 0.18%

512 CPUS offstack

 	7.8916 sec + 0.44%

Kernel size comparison:

    text		   data	    filename				Difference to onstack256 baseline
25755648	9589248	    vmlinuz-6.8.0-rc4-onstack256
25755648	9607680	    vmlinuz-6.8.0-rc4-onstack512	+0.19%
25755648	9603584	    vmlinuz-6.8.0-rc4-offstack512	+0.14%

Tested-by: Eric Mackay <eric.mackay@oracle.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Christoph Lameter (Ampere) <cl@linux.com>
---


Original post: https://www.spinics.net/lists/linux-mm/msg369701.html
V2: https://lkml.org/lkml/2024/2/7/505


V1->V2

- Keep quotation marks
- Remove whiltespace damage
- Add tested by

V2->V3:
- Add test results
- Rework descriptions


  arch/arm64/Kconfig | 16 +++++++++++++++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index aa7c1d435139..4e767dede47d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1427,7 +1427,21 @@ config SCHED_SMT
  config NR_CPUS
  	int "Maximum number of CPUs (2-4096)"
  	range 2 4096
-	default "256"
+	default "512"
+
+#
+# Determines the placement of cpumasks.
+#
+# With CPUMASK_OFFSTACK the cpumasks are dynamically allocated.
+# Useful for machines with lots of core because it avoids increasing
+# the size of many of the data structures in the kernel.
+#
+# If this is off then the cpumasks have a static sizes and are
+# embedded within data structures.
+#
+	config CPUMASK_OFFSTACK
+	def_bool y
+	depends on NR_CPUS > 256

  config HOTPLUG_CPU
  	bool "Support for hot-pluggable CPUs"
-- 
2.39.2


WARNING: multiple messages have this Message-ID (diff)
From: "Christoph Lameter (Ampere)" <cl@gentwo.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: catalin.marinas@arm.com, Will Deacon <will@kernel.org>,
	 Jonathan.Cameron@huawei.com, Matteo.Carlini@arm.com,
	 Valentin.Schneider@arm.com, akpm@linux-foundation.org,
	 anshuman.khandual@arm.com, Eric Mackay <eric.mackay@oracle.com>,
	 dave.kleikamp@oracle.com, linux-arm-kernel@lists.infradead.org,
	 linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux@armlinux.org.uk,  robin.murphy@arm.com,
	vanshikonda@os.amperecomputing.com,  yang@os.amperecomputing.com
Subject: [PATCH v3] ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512
Date: Wed, 6 Mar 2024 17:45:04 -0800 (PST)	[thread overview]
Message-ID: <37099a57-b655-3b3a-56d0-5f7fbd49d7db@gentwo.org> (raw)

Currently defconfig selects NR_CPUS=256, but some vendors (e.g. Ampere
Computing) are planning to ship systems with 512 CPUs. So that all CPUs on
these systems can be used with defconfig, we'd like to bump NR_CPUS to 512.
Therefore this patch increases the default NR_CPUS from 256 to 512.

As increasing NR_CPUS will increase the size of cpumasks, there's a fear that
this might have a significant impact on stack usage due to code which places
cpumasks on the stack. To mitigate that concern, we can select
CPUMASK_OFFSTACK. As that doesn't seem to be a problem today with
NR_CPUS=256, we only select this when NR_CPUS > 256.

CPUMASK_OFFSTACK configures the cpumasks in the kernel to be
dynamically allocated. This was used in the X86 architecture in the
past to enable support for larger CPU configurations up to 8k cpus.

With that is becomes possible to dynamically size the allocation of
the cpu bitmaps depending on the quantity of processors detected on
bootup. Memory used for cpumasks will increase if the kernel is
run on a machine with more cores.

Further increases may be needed if ARM processor vendors start
supporting more processors. Given the current inflationary trends
in core counts from multiple processor manufacturers this may occur.

There are minor regressions for hackbench. The kernel data size
for 512 cpus is smaller with offstack than with onstack.

Benchmark results using hackbench average over 10 runs of

 	hackbench -s 512 -l 2000 -g 15 -f 25 -P

on Altra 80 Core

Support for 256 CPUs on stack. Baseline

 	7.8564 sec

Support for 512 CUs on stack.

 	7.8713 sec + 0.18%

512 CPUS offstack

 	7.8916 sec + 0.44%

Kernel size comparison:

    text		   data	    filename				Difference to onstack256 baseline
25755648	9589248	    vmlinuz-6.8.0-rc4-onstack256
25755648	9607680	    vmlinuz-6.8.0-rc4-onstack512	+0.19%
25755648	9603584	    vmlinuz-6.8.0-rc4-offstack512	+0.14%

Tested-by: Eric Mackay <eric.mackay@oracle.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Christoph Lameter (Ampere) <cl@linux.com>
---


Original post: https://www.spinics.net/lists/linux-mm/msg369701.html
V2: https://lkml.org/lkml/2024/2/7/505


V1->V2

- Keep quotation marks
- Remove whiltespace damage
- Add tested by

V2->V3:
- Add test results
- Rework descriptions


  arch/arm64/Kconfig | 16 +++++++++++++++-
  1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index aa7c1d435139..4e767dede47d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1427,7 +1427,21 @@ config SCHED_SMT
  config NR_CPUS
  	int "Maximum number of CPUs (2-4096)"
  	range 2 4096
-	default "256"
+	default "512"
+
+#
+# Determines the placement of cpumasks.
+#
+# With CPUMASK_OFFSTACK the cpumasks are dynamically allocated.
+# Useful for machines with lots of core because it avoids increasing
+# the size of many of the data structures in the kernel.
+#
+# If this is off then the cpumasks have a static sizes and are
+# embedded within data structures.
+#
+	config CPUMASK_OFFSTACK
+	def_bool y
+	depends on NR_CPUS > 256

  config HOTPLUG_CPU
  	bool "Support for hot-pluggable CPUs"
-- 
2.39.2


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

             reply	other threads:[~2024-03-07  1:45 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-07  1:45 Christoph Lameter (Ampere) [this message]
2024-03-07  1:45 ` [PATCH v3] ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512 Christoph Lameter (Ampere)
2024-03-07 17:49 ` Mark Rutland
2024-03-07 17:49   ` Mark Rutland
2024-03-07 19:07 ` Catalin Marinas
2024-03-07 19:07   ` Catalin Marinas
2024-03-18 18:17   ` Catalin Marinas
2024-03-18 18:17     ` Catalin Marinas
     [not found] ` <CGME20240308140130eucas1p1259c805a0b6491ce2f69c6fca0264b1f@eucas1p1.samsung.com>
2024-03-08 14:01   ` Marek Szyprowski
2024-03-08 14:01     ` Marek Szyprowski
2024-03-08 14:51     ` Catalin Marinas
2024-03-08 14:51       ` Catalin Marinas
2024-03-08 16:21       ` Marek Szyprowski
2024-03-08 16:21         ` Marek Szyprowski
2024-03-08 17:08         ` Christoph Lameter (Ampere)
2024-03-08 17:08           ` Christoph Lameter (Ampere)
2024-03-11 12:12           ` Mark Rutland
2024-03-11 12:12             ` Mark Rutland
2024-03-11 14:56             ` Marek Szyprowski
2024-03-11 14:56               ` Marek Szyprowski
2024-03-11 15:22               ` Catalin Marinas
2024-03-11 15:22                 ` Catalin Marinas
2024-03-11 16:51                 ` Marek Szyprowski
2024-03-11 16:51                   ` Marek Szyprowski
2024-03-11 17:08                   ` Catalin Marinas
2024-03-11 17:08                     ` Catalin Marinas
2024-03-11 18:55     ` Catalin Marinas
2024-03-11 18:55       ` Catalin Marinas
2024-03-11 21:07       ` Christoph Lameter (Ampere)
2024-03-11 21:07         ` Christoph Lameter (Ampere)
2024-03-12 17:06         ` Christoph Lameter (Ampere)
2024-03-12 17:06           ` Christoph Lameter (Ampere)
2024-03-12 17:55           ` Catalin Marinas
2024-03-12 17:55             ` Catalin Marinas
2024-03-13 14:35             ` Sudeep Holla
2024-03-13 14:35               ` Sudeep Holla
2024-03-13 16:22               ` Marek Szyprowski
2024-03-13 16:22                 ` Marek Szyprowski
2024-03-13 16:39                 ` Christoph Lameter (Ampere)
2024-03-13 16:39                   ` Christoph Lameter (Ampere)
2024-03-13 20:18                   ` Marek Szyprowski
2024-03-13 20:18                     ` Marek Szyprowski
2024-03-13 17:13                 ` Russell King (Oracle)
2024-03-13 17:13                   ` Russell King (Oracle)
2024-03-14  8:39                   ` Catalin Marinas
2024-03-14  8:39                     ` Catalin Marinas
2024-03-14 12:28                     ` Marek Szyprowski
2024-03-14 12:28                       ` Marek Szyprowski
2024-03-14 13:17                       ` Russell King (Oracle)
2024-03-14 13:17                         ` Russell King (Oracle)
2024-03-14 17:01                         ` Christoph Lameter (Ampere)
2024-03-14 17:01                           ` Christoph Lameter (Ampere)
2024-03-14 13:57                       ` Catalin Marinas
2024-03-14 13:57                         ` Catalin Marinas

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=37099a57-b655-3b3a-56d0-5f7fbd49d7db@gentwo.org \
    --to=cl@gentwo.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=Matteo.Carlini@arm.com \
    --cc=Valentin.Schneider@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dave.kleikamp@oracle.com \
    --cc=eric.mackay@oracle.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=vanshikonda@os.amperecomputing.com \
    --cc=will@kernel.org \
    --cc=yang@os.amperecomputing.com \
    /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.