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

[Kai Huang <kaih.linux@gmail.com>]

On 05/07/2016 12: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.
Oh yes. This makes sense. This also counts a disadvantage of per-vcpu 
structure.

Thanks,
-Kai