Re: [PATCH 0/1] KVM: make get dirty log ioctl return the first dirty page's position

[Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>]

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.