Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 20 Jan 2003 14:32:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 20 Jan 2003 14:32:30 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]:38881 "EHLO e32.co.us.ibm.com") by vger.kernel.org with ESMTP id ; Mon, 20 Jan 2003 14:32:29 -0500 Date: Mon, 20 Jan 2003 11:33:45 -0800 From: "Martin J. Bligh" To: Andrew Theurer , Ingo Molnar cc: Erich Focht , Michael Hohnbaum , Matthew Dobson , Christoph Hellwig , Robert Love , Linus Torvalds , linux-kernel , lse-tech , Anton Blanchard Subject: Re: [patch] sched-2.5.59-A2 Message-ID: <262510000.1043091224@flay> In-Reply-To: <200301201313.39621.habanero@us.ibm.com> References: <200301201313.39621.habanero@us.ibm.com> X-Mailer: Mulberry/2.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >> > I think the large PPC64 boxes have multilevel NUMA as well - two real >> > phys cores on one die, sharing some cache (L2 but not L1? Anton?). And >> > SGI have multilevel nodes too I think ... so we'll still need multilevel >> > NUMA at some point ... but maybe not right now. >> >> Intel's HT is the cleanest case: pure logical cores, which clearly need >> special handling. Whether the other SMT solutions want to be handled via >> the logical-cores code or via another level of NUMA-balancing code, >> depends on benchmarking results i suspect. It will be one more flexibility >> that system maintainers will have, it's all set up via the >> sched_map_runqueue(cpu1, cpu2) boot-time call that 'merges' a CPU's >> runqueue into another CPU's runqueue. It's basically the 0th level of >> balancing, which will be fundamentally different. The other levels of >> balancing are (or should be) similar to each other - only differing in >> weight of balancing, not differing in the actual algorithm. > > I have included a very rough patch to do ht-numa topology. I requires to > manually define CONFIG_NUMA and CONFIG_NUMA_SCHED. It also uses num_cpunodes > instead of numnodes and defines MAX_NUM_NODES to 8 if CONFIG_NUMA is defined. Whilst it's fine for benchmarking, I think this kind of overlap is a very bad idea long-term - the confusion introduced is just asking for trouble. And think what's going to happen when you mix HT and NUMA. If we're going to use this for HT, it needs abstracting out. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/