login
Search
Paul Jackson from SGI recently posted a patch to the Linux kernel mailing list explaining, "It's needed to build NR_CPUS > 256."
SGI has already delivered a custom Altix single system image supercomputer to NASA Ames Research Center with 256 processors running Linux, and their 64 processor Linux systems are generally available.
This latest patch seems to indicate that SGI is testing or getting ready to test Linux 2.6 on a machine with more than 256 processors. This would be a great testament to the scalability of the new kernel.
From: Paul Jackson [email blocked]
To: Andrew Morton [email blocked]
Subject: [PATCH] > 256 CPU cpumask build fix - const confusion
Date: Tue, 4 Nov 2003 19:57:28 -0800
Please apply the following patch. It's needed to build NR_CPUS > 256.
Without this fix, you get compile errors:
include/linux/cpumask.h: In function `next_online_cpu':
include/linux/cpumask.h:56: structure has no member named `val'
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1357 -> 1.1358
# include/linux/cpumask.h 1.1 -> 1.2
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/11/04 [email blocked] 1.1358
# Fix cpumask const confusion if NR_CPUS > 128 (i386) or > 256 (ia64).
# --------------------------------------------
#
diff -Nru a/include/linux/cpumask.h b/include/linux/cpumask.h
--- a/include/linux/cpumask.h Tue Nov 4 19:31:30 2003
+++ b/include/linux/cpumask.h Tue Nov 4 19:31:30 2003
@@ -53,18 +53,18 @@
static inline int next_online_cpu(int cpu, cpumask_t map)
{
do
- cpu = next_cpu_const(cpu, map);
+ cpu = next_cpu_const(cpu, mk_cpumask_const(map));
while (cpu < NR_CPUS && !cpu_online(cpu));
return cpu;
}
#define for_each_cpu(cpu, map) \
- for (cpu = first_cpu_const(map); \
+ for (cpu = first_cpu_const(mk_cpumask_const(map)); \
cpu < NR_CPUS; \
- cpu = next_cpu_const(cpu,map))
+ cpu = next_cpu_const(cpu,mk_cpumask_const(map)))
#define for_each_online_cpu(cpu, map) \
- for (cpu = first_cpu_const(map); \
+ for (cpu = first_cpu_const(mk_cpumask_const(map)); \
cpu < NR_CPUS; \
cpu = next_online_cpu(cpu,map))
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [email blocked] 1.650.933.1373
Confirmed!
It seems SGI _is_ testing bigger systems. Jack Steiner from SGI recently posted a scalability problem he discovered with IA64's new interrupt code implementation.
He mentioned that his 500(!!!) processor system was booting fine after a quick hack to fix the problem. He didn't indicate the kernel efficiency at that level, but presumably SGI thinks 2.6 has the potential.
And from all the benchmarks I have seen, 2.6 has not badly compromised small uniprocessor performance at all. There are some tradeoffs, like rmap, and other more complex algorithms, but these also help performance in other areas, as seen in a recent "algorithmic scalability" report.