Inside Constant-Time (O(1)) Memory Snapshot Restore — Diff Restore and the UFFD Architecture
A note on the figures: every performance number given here was measured in-house on the Vantisso internal benchmark environment (8 vCPU, a single NVMe SSD), derived from API response times and system logs.
Diff restore: concept and advantages
In VM-based infrastructure, and in serverless environments in particular, the ability to save and restore VM state quickly determines the performance of the system as a whole. Writing a full memory dump to disk every time the state of a running VM has to be preserved is itself a serious I/O bottleneck. Diff restore is a structural answer to that inefficiency. Taking the base full snapshot created first as its reference, it tracks only the pages modified afterwards (dirty pages) and overlays them as sparse diff data. Because the whole of memory never has to be written out, creating a diff snapshot completes in just 0.04 s. That drives disk I/O and storage consumption down dramatically, which makes it an essential technique wherever state is saved frequently.
Two architectures for implementing diff restore
Architectures that read a diff snapshot, reconstruct the VM's memory and restore it fall broadly into two categories.
1. Full-image merge
Before the restore itself, the base image is copied and the diff data written over it, physically reconstructing a single image the size of the full guest memory. To mitigate disk I/O latency, this merge is normally carried out on tmpfs (/dev/shm), a RAM-backed temporary file system. The VM then reads the reconstructed single image.
2. Userfaultfd (UFFD) based on-demand restore (layered backend)
This approach removes the physical image merge from the path altogether. The base image is only mapped into memory (mmap), and the VM starts running immediately from that state. Once it is running, when the VM touches a memory page and the kernel raises a page fault, a UFFD handler inside the process intercepts it. The handler serves the page from the diff data if the page is present there, and from the base image on demand if it is not. Under this mechanism, an image the size of the full guest RAM never has to be materialized at all.
Comparative analysis against measured data
The performance gap between the two architectures becomes more pronounced as the guest memory (RAM) allocated to the VM grows. Full-image merge entails a data copy proportional to the total capacity, so it carries a structural limit: restore latency rises linearly with guest RAM size (RAM-linear). Building the environment and measuring it, the merge operation took roughly 0.41 s per GB. Comparing the 512 MB Standard profile that Vantisso recommends as its default with the 2048 MB Max profile makes the capacity-proportional trend unmistakable.
- 512 MB RAM: approx. 0.28 s
- 1024 MB RAM: approx. 0.41 s
- 2048 MB RAM: approx. 0.97 s
The UFFD-based on-demand approach, by contrast, does away with the merge stage itself: only the working set the VM actually touches early in its run is faulted in and loaded on the spot, so nothing on the path scales with the amount of RAM allocated. Measured in the same environment as the full-image merge tests, UFFD restore times are as follows.
- 512 MB RAM: 0.140 s
- 1024 MB RAM: 0.141 s
- 2048 MB RAM: 0.142 s
The value of RAM-independent, constant-time (O(1)) restore
The tests make it clear that UFFD-based diff restore holds a technical advantage over the alternative arrangement. By removing the compute time otherwise lost to a linear memory merge, a large AI agent running with 2048 MB of RAM can expect roughly a 6.5× improvement when its snapshot is restored through the UFFD-based on-demand path rather than through a full-image merge. What deserves particular attention is that restore latency holds constant, entirely independent of guest RAM size (RAM-independent). Combining the disk I/O optimization of diff storage with UFFD-based constant-time restore increases the density of AI agents an execution infrastructure can carry, which is why we recommend putting it to active use when designing Agentic AI infrastructure.