[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 00/27] Migration thread (WIP)

From: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC 00/27] Migration thread (WIP)
Date: Thu, 26 Jul 2012 12:57:07 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

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.


Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux

reply via email to

[Prev in Thread] Current Thread [Next in Thread]