Overview

M3U supports a conditional yes for high-end post-copy: it becomes more workable when pre-copy convergence is unreliable and the host treats switching, urgent faults, bulk transfer, and device DMA as separate jobs. Static placement and flagging reduce stopped-time work; PVA and mixed granularity separate copying from consistency updates; device-state pre-installation avoids predictable IOPFs. Reported gains are substantial in the evaluated prototype, but applicability remains bounded by versions, hardware, devices, guest transparency, memory backing, and post-copy’s split-state failure boundary.

Learning outcomes

Post-copy can escape pre-copy convergence, but practical scalability requires controlling the memory-management work exposed after resumption.
M3U aligns page flagging, PVA recovery, mixed granularity, and device-state pre-installation with different migration time scales.
The measured gains support conditional scalability in the evaluated environment, not universal performance or failure tolerance.

Keywords

M3UScalabilityPost-copyConvergencePVAIOPF

When Can Post-Copy Scale for High-End VMs?

M3U answers a narrow but important systems question: can post-copy live migration remain usable when a VM is large enough to defeat pre-copy and busy enough to expose every serialized memory-management step? The evidence supports a conditional yes. Post-copy is the right escape from a convergence race, but it becomes practical at high-end scale only when the host treats switching, urgent page faults, bulk transfer, and device DMA as different jobs with different timing needs. M3U demonstrates that principle in a tested prototype; it does not turn the result into a universal guarantee.

Scalability starts with the migration invariant

The decisive distinction is between making migration possible and making it good for the guest. Pre-copy can preserve the guest's normal execution while it transfers memory, but it asks the source to keep producing dirty pages until the remaining set falls below a stopping threshold. A high-end workload can violate that condition. The paper's analysis of more than 50,000 pre-copy samples from its cloud infrastructure reports an 81% success rate and attributes the failures to convergence. That figure belongs to one infrastructure and sample, but the mechanism is general: if the guest writes memory faster than the migration path drains it, repetition becomes the obstacle.

Post-copy changes the invariant instead of trying to make the repetition more efficient. The source stops running, the destination resumes before every page has arrived, and the missing memory is recovered through demand paging and background pushing. Because the source no longer keeps dirtying the VM, the remaining transfer has a finite path to completion. This is why post-copy is strategically attractive for a large, write-intensive VM. It turns an open-ended production race into a dependency problem between a running destination and a source that still holds some required pages.

That dependency is also why post-copy's feasibility advantage creates three quality problems. The first appears before the destination resumes. The remaining dirty pages must be marked unavailable, and a conventional path can spend most of the stopped interval unmapping them. The second appears after resumption. A missing page must be copied and made consistent across the host's memory-management structures while the guest continues executing. The third appears when a pass-through device issues DMA to one of those missing pages. The resulting I/O page fault can stall a device queue through a hardware and host-interrupt path.

These costs are related, but they are not one cost that can be solved by “making migration faster.” They occupy different phases and have different owners. Dirty registration is a switching-time problem. Page recovery is a sustained interaction between background transfer, urgent demand faults, and translation updates. A device fault is a consumer-side queue problem. A system that applies the same lock, page size, or scheduling policy to all three paths can be correct and still be unusable at high-end scale.

The M3U paper makes that distinction concrete with a high-end definition of at least 64 vCPUs and 256 GB of memory. Those numbers define the paper's evaluation scope, not a universal threshold. At that size, a 128 GB working set can require up to 32 million unmap operations during registration, and dirty-page registration accounts for 57–66% of downtime in the tested configurations. After resumption, the baseline uses only 9.2% of the available physical network bandwidth in the cited experiment, while a 24 GB remaining set takes 24 seconds to recover against a 3.84-second idealized transfer time. The link is not the only system in the loop; memory-management work stands in front of it.

The right mental model is therefore a chain of constraints:

Pre-copy may not converge because execution keeps generating dirty memory.
Post-copy makes progress by allowing the destination to run with missing pages.
Missing pages expose the cost of marking memory absent, fetching it, installing it, and keeping translations consistent.
High-end concurrency turns broad locks and fixed granularity into queues.
Pass-through devices add a hardware-mediated fault path that can block I/O rather than only one guest thread.

This chain explains why a high-end post-copy design must be evaluated by more than total migration time. Downtime asks whether the switching window is tolerable. Post-copy completion time asks whether the guest can recover its working set. Paging efficiency asks whether the transfer machinery uses the link. Guest performance asks what the application experiences. IOPF count asks whether pass-through devices repeatedly enter the expensive fault path.