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

[David Hildenbrand <david@redhat.com>]

On 21.01.21 16:24, andrey.gruzdev--- via wrote:
> This patch series is a kind of 'rethinking' of Denis Plotnikov's ideas he's
> implemented in his series '[PATCH v0 0/4] migration: add background snapshot'.
> 
> Currently the only way to make (external) live VM snapshot is using existing
> dirty page logging migration mechanism. The main problem is that it tends to
> produce a lot of page duplicates while running VM goes on updating already
> saved pages. That leads to the fact that vmstate image size is commonly several
> times bigger then non-zero part of virtual machine's RSS. Time required to
> converge RAM migration and the size of snapshot image severely depend on the
> guest memory write rate, sometimes resulting in unacceptably long snapshot
> creation time and huge image size.
> 
> This series propose a way to solve the aforementioned problems. This is done
> by using different RAM migration mechanism based on UFFD write protection
> management introduced in v5.7 kernel. The migration strategy is to 'freeze'
> guest RAM content using write-protection and iteratively release protection
> for memory ranges that have already been saved to the migration stream.
> At the same time we read in pending UFFD write fault events and save those
> pages out-of-order with higher priority.
> 

Hi,

just stumbled over this, quick question:

I recently played with UFFD_WP and notices that write protection is only 
effective on pages/ranges that have already pages populated (IOW: 
!pte_none() in the kernel).

In case memory was never populated (or was discarded using e.g., 
madvice(DONTNEED)), write-protection will be skipped silently and you 
won't get WP events for applicable pages.

So if someone writes to a yet unpoupulated page ("zero"), you won't get 
WP events.

I can spot that you do a single uffd_change_protection() on the whole 
RAMBlock.

How are you handling that scenario, or why don't you have to handle that 
scenario?

-- 
Thanks,

David / dhildenb