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
