From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCmOo-0000Qa-4a for qemu-devel@nongnu.org; Fri, 23 Aug 2013 04:07:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCmOi-0002Up-3Y for qemu-devel@nongnu.org; Fri, 23 Aug 2013 04:07:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCmOh-0002Ug-SV for qemu-devel@nongnu.org; Fri, 23 Aug 2013 04:07:08 -0400 Message-ID: <521717EB.7020406@redhat.com> Date: Fri, 23 Aug 2013 10:06:03 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1377069536-12658-1-git-send-email-lilei@linux.vnet.ibm.com> <1377069536-12658-14-git-send-email-lilei@linux.vnet.ibm.com> <52149B09.705@redhat.com> <52170060.4050104@linux.vnet.ibm.com> <521713DA.9010903@redhat.com> <18FE72B095A0C28E7B5AD40D@nimrod.local> In-Reply-To: <18FE72B095A0C28E7B5AD40D@nimrod.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 13/18] arch_init: adjust ram_save_setup() for migrate_is_localhost List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: aarcange@redhat.com, Lei Li , quintela@redhat.com, qemu-devel@nongnu.org, mrhines@linux.vnet.ibm.com, Anthony Liguori , lagarcia@br.ibm.com, rcj@linux.vnet.ibm.com Il 23/08/2013 09:57, Alex Bligh ha scritto: > > > --On 23 August 2013 09:48:42 +0200 Paolo Bonzini > wrote: > >> As a matter of fact, 2^28 madvise system calls will take much, much >> longer than 100ms. > > Probably a stupid question, but why would you need to do one call per > page? It takes a 'size_t length' parameter. Right now migration is done a page at a time, and so is madvise AFAIU. However, even with a larger length parameter I suspect it would alone take more than 2 cycles per page. So one way to do this could be to add a flag to "migrate" that would migrate devices only, and use shared memory in both the source and the target. There is still a problem, because we must make sure the destination doesn't write to memory (e.g. read firmware) when initializing the board, because that would overwrite the memory of the running instance. But it looks more promising than page flipping. Paolo