You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Heuristic-based scratch zeroing strategy for snapshot restore #1766
HostSharedMemory::zero_or_replace() currently uses a compile-time #[cfg(target_os = "windows")] check to decide whether to zero scratch in-place or replace it with a fresh demand-zero allocation. This works for the immediate problem (large scratch regions on WHP), but the real decision depends on the hypervisor and the size of the region, not just the platform.
There is a break-even point between zero-in-place (via MADV_DONTNEED or fill(0)) and delete+recreate (fresh ExclusiveSharedMemory::new) that varies by:
Hypervisor (KVM, MSHV, WHP)
Scratch region size
Whether MADV_DONTNEED is available (KVM-only builds vs KVM+mshv3)
We should benchmark across these configurations and replace the compile-time platform check with a size-based heuristic. This would also allow MSHV builds on Linux to benefit from the fresh-allocation path for large scratch regions.
Activity
perf(sandbox): reset scratch from the dirty log on MSHV and WHP
perf(sandbox): reset scratch from the dirty log on MSHV and WHP
perf(sandbox): reset scratch from the dirty log on MSHV and WHP
perf(sandbox): reset scratch from the dirty log on MSHV and WHP
perf(sandbox): reset scratch from the dirty log on MSHV and WHP
amend! perf(sandbox): reset scratch from the dirty log on MSHV and WHP