From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWAmG-0006N4-D9 for qemu-devel@nongnu.org; Thu, 01 Dec 2011 12:50:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RWAmC-0004Gp-9o for qemu-devel@nongnu.org; Thu, 01 Dec 2011 12:50:32 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]:44786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RWAmC-0004GC-3D for qemu-devel@nongnu.org; Thu, 01 Dec 2011 12:50:28 -0500 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 1 Dec 2011 10:50:24 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pB1HoAad100232 for ; Thu, 1 Dec 2011 10:50:14 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pB1Ho9Sx006059 for ; Thu, 1 Dec 2011 10:50:10 -0700 Date: Thu, 1 Dec 2011 23:19:56 +0530 From: Dipankar Sarma Message-ID: <20111201174956.GB26737@in.ibm.com> References: <1321889126.28118.5.camel@twins> <20111121160001.GB3602@in.ibm.com> <1321894980.28118.16.camel@twins> <4ECB0019.7020800@codemonkey.ws> <20111123150300.GH8397@redhat.com> <4ECD3CBD.7010902@suse.de> <20111130162237.GC27308@in.ibm.com> <20111130174113.GM23466@redhat.com> <20111201172520.GA26737@in.ibm.com> <20111201173623.GV23466@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111201173623.GV23466@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding Reply-To: dipankar@in.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: Peter Zijlstra , kvm list , qemu-devel Developers , Alexander Graf , Chris Wright , bharata@linux.vnet.ibm.com, Vaidyanathan S On Thu, Dec 01, 2011 at 06:36:23PM +0100, Andrea Arcangeli wrote: > On Thu, Dec 01, 2011 at 10:55:20PM +0530, Dipankar Sarma wrote: > > On Wed, Nov 30, 2011 at 06:41:13PM +0100, Andrea Arcangeli wrote: > > > On Wed, Nov 30, 2011 at 09:52:37PM +0530, Dipankar Sarma wrote: > > > > create the guest topology correctly and optimize for NUMA. This > > > > would work for us. > > > > > > Even on the case of 1 guest that fits in one node, you're not going to > > > max out the full bandwidth of all memory channels with this. > > > > > > qemu all can do with ms_mbind/tbind is to create a vtopology that > > > matches the hardware topology. It has these limits: > > > > > > 1) requires all userland applications to be modified to scan either > > > the physical topology if run on host, or the vtopology if run on > > > guest to get the full benefit. > > > > Not sure why you would need that. qemu can reflect the > > topology based on -numa specifications and the corresponding > > ms_tbind/mbind in FDT (in the case of Power, I guess ACPI > > tables for x86) and guest kernel would detect this virtualized > > topology. So there is no need for two types of topologies afaics. > > It will all be reflected in /sys/devices/system/node in the guest. > > The point is: what a vtopology gives you? If you don't modify all apps > running in the guest to use it? vtopology on guest, helps exactly like > the topology on host -> very little unless you modify qemu on host to > use ms_tbind/mbind. Sure, ms_tbind/mbind will be needed in qemu. For the rest, NUMA aware apps already use topology while running on physical systems and they wouldn't need modification for this kind of virtualized topology. Thanks Dipankar