From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 0A0852C00CC for ; Wed, 19 Feb 2014 04:36:53 +1100 (EST) Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 18 Feb 2014 10:36:51 -0700 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 5D9CC19D8042 for ; Tue, 18 Feb 2014 10:36:48 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by b03cxnp08026.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s1IHaQ7u9175498 for ; Tue, 18 Feb 2014 18:36:26 +0100 Received: from d03av02.boulder.ibm.com (localhost [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s1IHakTa003697 for ; Tue, 18 Feb 2014 10:36:49 -0700 Date: Tue, 18 Feb 2014 09:28:33 -0800 From: Nishanth Aravamudan To: Christoph Lameter Subject: Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node Message-ID: <20140218172832.GD31998@linux.vnet.ibm.com> References: <20140207054819.GC28952@lge.com> <20140210191321.GD1558@linux.vnet.ibm.com> <20140211074159.GB27870@lge.com> <20140213065137.GA10860@linux.vnet.ibm.com> <20140217070051.GE3468@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Cc: Han Pingtian , Matt Mackall , Pekka Enberg , Linux Memory Management List , Paul Mackerras , Anton Blanchard , David Rientjes , Joonsoo Kim , linuxppc-dev@lists.ozlabs.org, Wanpeng Li List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 18.02.2014 [10:57:09 -0600], Christoph Lameter wrote: > On Mon, 17 Feb 2014, Joonsoo Kim wrote: > > > On Wed, Feb 12, 2014 at 10:51:37PM -0800, Nishanth Aravamudan wrote: > > > Hi Joonsoo, > > > Also, given that only ia64 and (hopefuly soon) ppc64 can set > > > CONFIG_HAVE_MEMORYLESS_NODES, does that mean x86_64 can't have > > > memoryless nodes present? Even with fakenuma? Just curious. > > x86_64 currently does not support memoryless nodes otherwise it would > have set CONFIG_HAVE_MEMORYLESS_NODES in the kconfig. Memoryless nodes are > a bit strange given that the NUMA paradigm is to have NUMA nodes (meaning > memory) with processors. MEMORYLESS nodes means that we have a fake NUMA > node without memory but just processors. Not very efficient. Not sure why > people use these configurations. Well, on powerpc, with the hypervisor providing the resources and the topology, you can have cpuless and memoryless nodes. I'm not sure how "fake" the NUMA is -- as I think since the resources are virtualized to be one system, it's logically possible that the actual topology of the resources can be CPUs from physical node 0 and memory from physical node 2. I would think with KVM on a sufficiently large (physically NUMA x86_64) and loaded system, one could cause the same sort of configuration to occur for a guest? In any case, these configurations happen fairly often on long-running (not rebooted) systems as LPARs are created/destroyed, resources are DLPAR'd in and out of LPARs, etc. > > I don't know, because I'm not expert on NUMA system :) > > At first glance, fakenuma can't be used for testing > > CONFIG_HAVE_MEMORYLESS_NODES. Maybe some modification is needed. > > Well yeah. You'd have to do some mods to enable that testing. I might look into it, as it might have sped up testing these changes. Thanks, Nish