Re: [PATCH v2 0/6] migration/ram: Optimize for virtio-mem via RamDiscardManager

[David Hildenbrand <david@redhat.com>]

>>>>> The thing is I still think this extra operation during sync() can be ignored by
>>>>> simply clear dirty log during bitmap init, then.. why not? :)
>>>>
>>>> I guess clearing the dirty log (especially in KVM) might be more expensive.
>>>
>>> If we send one ioctl per cb that'll be expensive for sure.  I think it'll be
>>> fine if we send one clear ioctl to kvm, summarizing the whole bitmap to clear.
>>>
>>> The other thing is imho having overhead during bitmap init is always better
>>> than having that during sync(). :)
>>
>> Oh, right, so you're saying, after we set the dirty bmap to all ones and
>> excluded the discarded parts, setting the respective bits to 0, we simply
>> issue clearing of the whole area?
>>
>> For now I assumed we would have to clear per cb.
> 
> Hmm when I replied I thought we can pass in a bitmap to ->log_clear() but I
> just remembered memory API actually hides the bitmap interface..
> 
> Reset the whole region works, but it'll slow down migration starts, more
> importantly that'll be with mmu write lock so we will lose most clear-log
> benefit for the initial round of migration and stuck the guest #pf at the
> meantime...
> 
> Let's try do that in cb()s as you mentioned; I think that'll still be okay,
> because so far the clear log block size is much larger (1gb), 1tb is worst case
> 1000 ioctls during bitmap init, slightly better than 250k calls during sync(),
> maybe? :)

Just to get it right, what you propose is calling 
migration_clear_memory_region_dirty_bitmap_range() from each cb(). Due 
to the clear_bmap, we will end up clearing each chunk (e.g., 1GB) at 
most once.

But if our layout is fragmented, we can actually end up clearing all 
chunks (1024 ioctls for 1TB), resulting in a slower migration start.

Any gut feeling how much slower migration start could be with largish 
(e.g., 1 TiB) regions?

-- 
Thanks,

David / dhildenb