From: hawkes@sgi.com
To: Tony Luck <tony.luck@gmail.com>, Andrew Morton <akpm@osdl.org>,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Jack Steiner <steiner@sgi.com>, Dan Higgins <djh@sgi.com>,
hawkes@sgi.com, John Hesterberg <jh@sgi.com>,
Greg Edwards <edwardsg@sgi.com>
Subject: [PATCH] ia64: change defconfig to NR_CPUS==1024
Date: Thu, 5 Jan 2006 13:39:48 -0800 (PST) [thread overview]
Message-ID: <20060105213948.11412.45463.sendpatchset@tomahawk.engr.sgi.com> (raw)
Increase the generic ia64 config from its current max of 512 CPUs to a
new max of 1024 CPUs.
The principal file change that implements this is arch/ia64/defconfig,
which currently defines CONFIG_NR_CPUS=512. The change to
arch/ia64/Kconfig brings that file's declaration of the NR_CPUS default
up to the new reality of 1024. That Kconfig currently says
default "64"
which is bogus -- it is currently 512.
The recent change to arch/ia64/configs/sn2_defconfig just raised that
platform-specific defconfig to ==1024.
The rationale for increasing the generic ia64 defconfig to 1024 is that
the generic config needs to support the new upcoming max CPU count for
ia64 platforms, which for ia64/sn ("Altix") platform is 1024, just as
the current max of 512 supports the current max CPU count.
The downside is that the ia64 cpumask increases from 8 words to 16.
I have tried various heavy workloads and have seen no significant
measurable performance regression from this increase. The potential
extra cachemiss seems to be lost in the noise. The for_each_*cpu()
macros are relatively efficient in skipping past zeroed cpumask bits.
Workloads that impose higher loads on the CPU Scheduler tend to
bottleneck on non-Scheduler parts of the kernel, and it's the Scheduler
which makes the principal use of the cpumask_t, so these extra
cachemiss inefficiencies and extra CPU cycles to scan zero mask words
just get lost in the general system overhead.
Signed-off-by: John Hawkes <hawkes@sgi.com>
Acked-by: Jack Steiner <steiner@sgi.com>
Acked-by: Greg Edwards <edwardsg@sgi.com>
Index: linux/arch/ia64/Kconfig
===================================================================
--- linux.orig/arch/ia64/Kconfig 2006-01-02 19:21:10.000000000 -0800
+++ linux/arch/ia64/Kconfig 2006-01-04 10:32:50.000000000 -0800
@@ -245,7 +245,7 @@
int "Maximum number of CPUs (2-1024)"
range 2 1024
depends on SMP
- default "64"
+ default "1024"
help
You should set this to the number of CPUs in your system, but
keep in mind that a kernel compiled for, e.g., 2 CPUs will boot but
Index: linux/arch/ia64/defconfig
===================================================================
--- linux.orig/arch/ia64/defconfig 2006-01-02 19:21:10.000000000 -0800
+++ linux/arch/ia64/defconfig 2006-01-04 10:32:50.000000000 -0800
@@ -98,7 +98,7 @@
# CONFIG_IA64_SGI_SN_XP is not set
CONFIG_FORCE_MAX_ZONEORDER=18
CONFIG_SMP=y
-CONFIG_NR_CPUS=512
+CONFIG_NR_CPUS=1024
CONFIG_HOTPLUG_CPU=y
# CONFIG_SCHED_SMT is not set
# CONFIG_PREEMPT is not set
next reply other threads:[~2006-01-05 21:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-05 21:39 hawkes [this message]
2006-01-05 22:33 ` [PATCH] ia64: change defconfig to NR_CPUS==1024 Chen, Kenneth W
2006-01-06 17:06 ` John Hawkes
2006-01-06 8:38 ` Arjan van de Ven
2006-01-12 0:09 ` Paul Jackson
2006-01-12 19:04 ` Christoph Lameter
-- strict thread matches above, loose matches on Subject: below --
2006-01-06 17:19 Luck, Tony
2006-01-06 17:24 ` Arjan van de Ven
2006-01-06 17:26 ` Matthew Wilcox
2006-01-06 17:45 Luck, Tony
2006-01-06 17:49 ` Matthew Wilcox
2006-01-06 18:04 ` Christoph Lameter
2006-01-06 18:07 ` Matthew Wilcox
2006-01-06 18:19 ` Randy.Dunlap
2006-01-06 18:37 ` Christoph Lameter
2006-01-06 18:59 ` Arjan van de Ven
2006-01-06 20:17 ` Alan Cox
2006-01-06 20:18 ` Randy.Dunlap
2006-01-06 20:42 ` Rohit Seth
2006-01-06 21:00 ` Dave Jones
2006-01-06 18:25 ` Adrian Bunk
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=20060105213948.11412.45463.sendpatchset@tomahawk.engr.sgi.com \
--to=hawkes@sgi.com \
--cc=akpm@osdl.org \
--cc=djh@sgi.com \
--cc=edwardsg@sgi.com \
--cc=jh@sgi.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=steiner@sgi.com \
--cc=tony.luck@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox