From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuLko-00047C-3X for qemu-devel@nongnu.org; Thu, 26 Jul 2012 06:57:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SuLkj-0006m4-VN for qemu-devel@nongnu.org; Thu, 26 Jul 2012 06:57:14 -0400 Received: from thoth.sbs.de ([192.35.17.2]:15052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SuLkj-0006lw-LQ for qemu-devel@nongnu.org; Thu, 26 Jul 2012 06:57:09 -0400 Message-ID: <50112283.70201@siemens.com> Date: Thu, 26 Jul 2012 12:57:07 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1343155012-26316-1-git-send-email-quintela@redhat.com> In-Reply-To: <1343155012-26316-1-git-send-email-quintela@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 00/27] Migration thread (WIP) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu-devel@nongnu.org On 2012-07-24 20:36, Juan Quintela wrote: > Hi > > This series are on top of the migration-next-v5 series just posted. > > First of all, this is an RFC/Work in progress. Just a lot of people > asked for it, and I would like review of the design. > > It does: > - get a new bitmap for migration, and that bitmap uses 1 bit by page > - it unfolds migration_buffered_file. Only one user existed. > - it simplifies buffered_file a lot. > > - About the migration thread, special attention was giving to try to > get the series review-able (reviewers would tell if I got it). > > Basic design: > - we create a new thread instead of a timer function > - we move all the migration work to that thread (but run everything > except the waits with the iothread lock. > - we move all the writting to outside the iothread lock. i.e. > we walk the state with the iothread hold, and copy everything to one buffer. > then we write that buffer to the sockets outside the iothread lock. > - once here, we move to writting synchronously to the sockets. > - this allows us to simplify quite a lot. > > And basically, that is it. Notice that we still do the iterate page > walking with the iothread held. Light testing show that we got > similar speed and latencies than without the thread (notice that > almost no optimizations done here yet). > > Appart of the review: > - Are there any locking issues that I have missed (I guess so) > - stop all cpus correctly. vm_stop should be called from the iothread, > I use the trick of using a bottom half to get that working correctly. > but this _implementation_ is ugly as hell. Is there an easy way > of doing it? vm_stop is prepared to be called from vcpu context as well. I'm not sure right now if we actually do, but the code is there. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux