Avi Kivity wrote:
Well, if 10% of the pages are dirty, the new ioctl will statistically
return something within the first 20% of the slot, so we can skip 10%
and have to do the next 90%. Given that we already walked the bitmap
once in the kernel and the saving is only in userspace, the average
saving in bitmap-walking is only 5%.
The patch's greatest benefit is if all pages are clean (100% saved) or
if just one page is dirty (50% saved) but that will be very rare. So
I think the return-on-churn here is too low.
Actually I do not know well about migration's use case in the actual
service system.
In our group, there is a Fault Tolerance project which uses migration's
functions for synchronization frequently. So I thought this may be helpful
to such cases, not confirmed yet.
Another issue I am thinking is the x86's bitmap allocation. Doing vmalloc()
every time is not nice, though I know it's needed.
btw, one idea I had was to allocate the bitmap in userspace and let the
kernel set bits directly. This reduces the amount of unswappable memory
the kernel allocates and reduces copying.
A problem with this is that userspace cannot just clear the bits, since
the kernel has to write-protect the pages again. I don't know how we
can do this without copying the bitmap.
Yes, seems difficult.
--
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
