You mean the total live migration time for the unmodified qemu and the
'you modified for test' qemu
are almost the same?
Not sure I understand the question, but if 'you modified for test' means
below modifications to save_zero_page(), then answer is no. Here is what
I tried, let’s say we have 3 versions of qemu (below timings are for
16GB idle guest with 12GB ballooned out)
v1. Unmodified qemu – absolutely not code change – Total Migration time
= ~7600ms (I rounded this one to ~8000ms)
v2. Modified qemu 1 – with proposed patch set (which skips both zero
pages scan and migrating control information for ballooned out pages) -
Total Migration time = ~5700ms
v3. Modified qemu 2 – only with changes to save_zero_page() as discussed
in previous mail (and of course using proposed patch set only to
maintain bitmap for ballooned out pages) – Total migration time is
irrelevant in this case.
Total Zero page scan time = ~1789ms
Total (save_page_header + qemu_put_byte(f, 0)) = ~556ms.
Everything seems to add up here (may not be exact) – 5700+1789+559 =
~8000ms
I see 2 factors that we have not considered in this add up a. overhead
for migrating balloon bitmap to target and b. as you mentioned below
overhead of qemu_clock_get_ns().