Re: [PATCH v13 0/5] UFFD write-tracking migration/snapshots

[Peter Xu]

On Mon, Feb 22, 2021 at 06:33:27PM +0100, David Hildenbrand wrote:
> On 22.02.21 18:29, Peter Xu wrote:
> > On Sat, Feb 20, 2021 at 02:59:42AM -0500, David Hildenbrand wrote:
> > > Live snapshotting ends up reading all guest memory (dirty bitmap starts 
> > > with all 1s), which is not what we want for virtio-mem - we don’t want to 
> > > read and migrate memory that has been discarded and has no stable content.
> > > 
> > > For ordinary migration we use the guest page hint API to clear bits in 
> > > the dirty bitmap after dirty bitmap sync. Well, if we don‘t do bitmap 
> > > syncs we‘ll never clear any dirty bits. That‘s the problem.
> > 
> > Using dirty bitmap for that information is less efficient, becase it's
> > definitely a larger granularity information than PAGE_SIZE.  If the 
> > disgarded
> > ranges are always continuous and at the end of a memory region, we should 
> > have
> > some parameter in the ramblock showing that where we got shrinked then we 
> > don't
> > check dirty bitmap at all, rather than always assuming used_length is the 
> > one.
> 
> They are randomly scattered across the whole RAMBlock. Shrinking/growing
> will be done to some degree in the future (but it won't get rid of the
> general sparse layout we can produce).

OK. Btw I think currently live snapshot should still be reading dirty bitmap,
so maybe it's still fine.  It's just that it's still not very clear to hide
virtio-mem information into dirty bitmap, imho, since that's not how we
interpret dirty bitmap - which is only for the sake of tracking page changes.

What's the granule of virtio-mem for this discard behavior?  Maybe we could
decouple it with dirty bitmap some day; if the unit is big enough it's also a
gain on efficiency so we skip in chunk rather than looping over tons of pages
knowing that they're discarded.

Thanks,

-- 
Peter Xu