Re: [PATCH 3/6] KVM: Dirty memory tracking for performant checkpointing and improved live migration

["Radim Krčmář" <rkrcmar@redhat.com>]

2016-05-06 15:13+0000, Cao, Lei:
> On 5/6/2016 8:09 AM, Radim Krčmář wrote:
>> 2016-05-06 21:46+1200, Kai Huang:
>>> On Thu, May 5, 2016 at 6:57 AM, Radim Krčmář <rkrcmar@redhat.com> wrote:
>>>> 2016-05-04 18:33+0000, Cao, Lei:
>>>>>  On 5/4/2016 1:15 PM, Cao, Lei wrote:
>>>>>>  On 5/4/2016 9:13 AM, Radim Krčmář wrote:
>>>>>>>  Good designs so far seem to be:
>>>>>>>   memslot -> lockless radix tree
>>>>>>>  and
>>>>>>>   vcpu -> memslot -> list  (memslot -> vcpu -> list)
>>>>>>>
>>>>>>
>>>>>>  There is no need for lookup, the dirty log is fetched in
>>>>>> sequence, so why use
>>>>>>  radix tree with added complexity but no benefit?
>>>>>>
>>>>>>  List can be designed to be lockless, so memslot -> lockless
>>>>>> fixed list?
>>>>>
>>>>>  Never mind, lookup is needed to avoid duplicates. We can use
>>>>> list+bitmap, but
>>>>>  it's obviously not as efficient as radix tree.
>>>>
>>>> Are duplicates a significant problem?
>>>>
>>>> (The dirtied page is marked as dirty, so we should have zero to very few
>>>>  duplicates, depending on how dirtying and vm-exit on write to clean
>>>> page
>>>>  cooperate.  Duplicates don't introduce any bugs and we could also check
>>>>  last few entries in the list to weed out most likely cases.)
>>>
>>> I don't think duplicated pages are significant problem. The point is we
>>> don't lose pages.
>>>
>>> I actually don't quite follow why there will be duplicated pages. Is it
>>> because lockless thing?
>> 
>> Not really.  The ugly bitmap to avoid duplicates in this series makes me
>> think that hardware does force an exit on multiple VCPUs if they
>> concurrently write to the same clear page.  A list, or any per-vcpu
>> structure, will have multiple dirty entries if that happens.
>> 
> 
> We do see tons of duplicates. Majority are from kvm updating guest time,
> steal time, and setting/clearing PV EOI.
> 
> Duplicates don't introduce bugs, but are undesirable, given a fixed-size
> dirty log.

Absolutely.  I didn't realize there were this many duplicates and no
method of filtering seems better than the bitmap.
Looking forward to performance comparison with a tree!

Thanks.