public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

             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