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

[Peter Xu <peterx@redhat.com>]

On Tue, Jul 27, 2021 at 11:25:09AM +0200, David Hildenbrand wrote:
> For 2) I see 3 options:
> 
> a) Sync everything, fixup the dirty bitmap, never clear the dirty log of
> discarded parts. It's fairly simple and straight forward, as I can simply
> reuse the existing helper. Something that's discarded will never be dirty,
> not even if a misbehaving guest touches memory it shouldn't. [this patch]
> 
> b) Sync only populated parts, no need to fixup the dirty bitmap, never clear
> the dirty log of discarded parts. It's a bit more complicated but achieves
> the same goal as a). [optimization I propose for the future]
> 
> c) Sync everything, don't fixup the dirty bitmap, clear the dirty log of
> discarded parts initially. There are ways we still might migrate discarded
> ranges, for example, if a misbehaving guest touches memory it shouldn't.
> [what you propose]
> 
> Is my understanding correct? Any reasons why we should chose c) over b) long
> term or c) over a) short term?

My major concern is we could do something during sync() for not a very good
reason by looping over virtio-mem bitmap for disgarded ranges - IIUC it should
be destined to be merely no-op if the guest is well-behaved, am I right?

Meanwhile, I still have no idea how much overhead the "loop" part could bring.
For a large virtio-mem region with frequent plugged/unplugged mem interacted,
it seems possible to take a while to me..  I have no solid idea yet.

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? :)

Clear dirty bitmap is as simple as "reprotect the pages" functional-wise - if
they are unplugged memory ranges, and they shouldn't be written by the guest
(we still allow reads even for virtio-mem compatibility), then I don't see it
an issue to wr-protect it using clear dirty log when bitmap init.

It still makes sense to me to keep the dirty/clear bitmap in-sync, at least
before your plan b proposal; leaving the dirty bits set forever on unplugged
memory is okay but just sounds a bit weird.

Though my concern is only valid when virtio-mem is used, so I don't have a
strong opinion on it as you maintains virtio-mem. I believe you will always
have a better judgement than me on that. Especially, when/if Dave & Juan have
no problem on that. :)

Thanks,

-- 
Peter Xu