On Fri, Oct 31, 2014 at 11:29:49AM +0800, zhanghailiang wrote: > Agreed, but for doing live memory snapshot (VM is running when do snapsphot), > we have to do this (block the write action), because we have to save the page before it > is dirtied by writing action. This is the difference, compared to pre-copy migration. Ah ha, I understand the difference now. I suppose that you have considered doing a traditional pre-copy migration (that is, passes over memory saving dirty pages, followed by a pause and a final dump of remaining dirty pages) to a file. Your approach has the advantage of having the VM pause time bounded by the time it takes to handle the userfault and do the write, as opposed to pre-copy migration which has a pause time bounded by the time it takes to do the final dump of dirty pages, which, in the worst case, is the time it takes to dump all of the guest memory! You could use the old fork & dump trick. Given that the guest's memory is backed by private VMA (as of a year ago when I last looked, is always the case for QEMU), you can have the kernel do the write protection for you. Essentially, you fork Qemu and, in the child process, dump the guest memory then exit. If the parent (including the guest) writes to guest memory, then it will fault and the kernel will copy the page. The fork & dump approach will give you the best performance w.r.t. guest pause times (i.e., just pausing for the COW fault handler), but it does have the distinct disadvantage of potentially using 2x the guest memory (i.e., if the parent process races ahead and writes to all of the pages before you finish the dump). To mitigate memory copying, you could madvise MADV_DONTNEED the child memory as you copy it. > Great! Do you plan to issue your patches to community? I mean is your work based on > qemu? or an independent tool (CRIU migration?) for live-migration? > Maybe i could fix the migration problem for ivshmem in qemu now, > based on softdirty mechanism. I absolutely plan on releasing these patches :-) CRIU was the first open-source userland I had planned on integrating with. At Google, I'm working with our home-grown Qemu replacement. However, I'd be happy to help with an effort to get softdirty integrated in Qemu in the future. > >Documentation/vm/soft-dirty.txt and pagemap.txt in case you aren't familiar. To > > I have read them cursorily, it is useful for pre-copy indeed. But it seems that > it can not meet my need for snapshot. > >make softdirty usable for live migration, I've added an API to atomically > >test-and-clear the bit and write protect the page. > > How can i find the API? Is it been merged in kernel's master branch already? Negative. I'll be sure to CC you when I start sending this stuff upstream. Peter -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
