On 02/24/2010 10:55 AM, Avi Kivity wrote:
On 02/24/2010 10:43 AM, Takuya Yoshikawa wrote:
Some weeks ago, OHMURA Kei revised the qemu-kvm's
dirty bitmap scan by accessing the bitmap as an
unsigned long array.
By reviewing this work more, we notice that kernel
side is doing a similar thing to check the bitmap is
all clean or not.
So I made a patch which makes the get dirty log ioctl
return the first dirty page position found by this check.
Though my test is not enough to show the effect of this
patch, the fact that this patch has no bad effect to both
performance and implementation logic and we can skip some
extra memory accesses and comparisons in userspace seems
to be suggesting this patch is promising, right?
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.
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.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
