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
