[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200801141230.56403.ak@suse.de>
Date: Mon, 14 Jan 2008 12:30:56 +0100
From: Andi Kleen <ak@...e.de>
To: Ingo Molnar <mingo@...e.hu>
Cc: travis@....com, Andrew Morton <akpm@...ux-foundation.org>,
Christoph Lameter <clameter@....com>,
Jack Steiner <steiner@....com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/10] x86: Reduce memory and intra-node effects with large count NR_CPUs
> i think this patchset already gives a net win, by moving stuff from
> NR_CPUS arrays into per_cpu area. (Travis please confirm that this is
> indeed what the numbers show)
Yes that is what his patchkit does, although I'm not sure he has addressed all NR_CPUS
pigs yet. The basic idea came out of some discussions we had at kernel summit on this
topic. It's definitely a step in the right direction.
Another problem is that NR_IRQS currently scales with NR_CPUs which is wrong too
(e.g. a hyperthreaded quad core/socket does not need 8 times as many
external interrupts as a single core/socket). And there are unfortunately a few
drivers that declare NR_IRQS arrays.
In general there are more scaling problems like this (e.g. it also doesn't make
sense to scale kernel threads for each CPU thread for example).
At some point we might need to separate CONFIG_NR_CPUS into a
CONFIG_NR_SOCKETS / CONFIG_NR_CPUS to address this, although full dynamic
scaling without configuration is best of course.
All can just be addressed step by step of course.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists