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

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

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.