From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andre Przywara" Subject: Re: [PATCH] (resent) NUMA node migration Date: Wed, 09 Jan 2008 15:35:49 +0100 Message-ID: <4784DBC5.3070009@amd.com> References: <476C40BE.1030907@amd.com> <20071222005315.GA11052@totally.trollied.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20071222005315.GA11052@totally.trollied.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: John Levon Cc: Ian.Pratt@eu.citrix.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org John Levon wrote: > On Fri, Dec 21, 2007 at 11:39:58PM +0100, Andre Przywara wrote: > >> accordingly. Only changes Python code in xend. I hope that the patch >> doesn't break XenAPI compatibility (adding a parameter seems fine?). >> >> # xm migrate --live --node= localhost >> is the number as shown with 'xm info' under node_to_cpu >> >> I am aware that using live migration isn't the best approach (takes >> twice the memory and quite some time), After thinking more about this, I came to the conclusion that this is not entirely true. If you want to transfer the guest from one node (with it's own memory) to another node (with it's own memory), then you would need to have this amount of memory available at the target anyway. The performance problem can maybe overcome by not using TCP/IP to loopback, but a more direct solution (or by reverting to a UNIX socket). >>but it's less intrusive and works >> fine (given localhost migration stability...) > > Is this really using localhost live migration to move a domain from one > NUMA node to another on the same host? Why isn't there a simpler way? Well, Ian described the "simpler way" (thanks for that), I would call it more elegant and efficient, but simpler is not the word that comes to mind... One advantage of this solution is that the guest stays the same and there is no interruption. Also one could think about migrating hot pages first and letting the rest be done in the background more slowly (this is how VMware does this). Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 277-84917 ----to satisfy European Law for business letters: AMD Saxony Limited Liability Company & Co. KG, Wilschdorfer Landstr. 101, 01109 Dresden, Germany Register Court Dresden: HRA 4896, General Partner authorized to represent: AMD Saxony LLC (Wilmington, Delaware, US) General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy