From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [PATCH 0/3][RFC] NUMA: add host side pinning Date: Fri, 25 Jun 2010 13:06:04 +0200 Message-ID: <4C248D9C.8040108@amd.com> References: <1277327377-29629-1-git-send-email-andre.przywara@amd.com> <4C2288DD.3020207@codemonkey.ws> <865764AB-4E51-4ED4-8832-AED6A237A9D3@suse.de> <4C233A6D.7030805@amd.com> <4C233DAB.60106@redhat.com> <4C2342D1.4090103@amd.com> <4C248C55.9020204@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Alexander Graf , Anthony Liguori , "kvm@vger.kernel.org" To: Jes Sorensen Return-path: Received: from va3ehsobe005.messaging.microsoft.com ([216.32.180.31]:59036 "EHLO VA3EHSOBE005.bigfish.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752612Ab0FYLKV (ORCPT ); Fri, 25 Jun 2010 07:10:21 -0400 In-Reply-To: <4C248C55.9020204@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Jes Sorensen wrote: > On 06/24/10 13:34, Andre Przywara wrote: >> Avi Kivity wrote: >>> On 06/24/2010 01:58 PM, Andre Przywara wrote: >>> Non-anonymous memory doesn't work well with ksm and transparent >>> hugepages. Is it possible to use anonymous memory rather than file >>> backed? >> I'd prefer non-file backed, too. But that is how the current huge pages >> implementation is done. We could use MAP_HUGETLB and declare NUMA _and_ >> huge pages as 2.6.32+ only. Unfortunately I didn't find an easy way to >> detect the presence of the MAP_HUGETLB flag. If the kernel does not >> support it, it seems that mmap silently ignores it and uses 4KB pages >> instead. > > Bit behind on the mailing list, but I think this look very promising. > > I really think it makes more sense to make QEMU aware of the NUMA setup > as well, rather than relying on numctl to do the work outside. > > One thing you need to consider is what happens with migration once a > user specifies -numa. IMHO it is acceptable to simply disable migration > for the given guest. Is that really a problem? You create the guest on the target with a NUMA setup specific to the target machine. That could mean that you pin multiple guest nodes to the same host node, but that shouldn't break something, right? The guest part can (and should be!) migrated along with all the other device state. I think this is still missing from the current implementation. > > Cheers, > Jes > > PS: Are you planning on submitting anything to Linux Plumbers Conference > about this? :) Yes, I was planning to submit a proposal, as I saw NUMA mentioned in the topics list. AFAIK the deadline is July 19th, right? That gives me another week after my vacation (for which I leave in a few minutes). Regards, Andre. -- Andre Przywara AMD-OSRC (Dresden) Tel: x29712