Heuristic-based scratch zeroing strategy for snapshot restore

Abierto
#1,766 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
infrastructure, performance

Línea de trabajo

Comienza con HostSharedMemory::zero_or_replace() y lee el contexto en #1765. Haz un benchmark de zero-in-place frente a delete-and-recreate en KVM, MSHV y WHP, variando los tamaños de las regiones scratch y la disponibilidad de MADV_DONTNEED. Se considera completado cuando la comprobación de Windows en tiempo de compilación se sustituye por una heurística basada en el tamaño que también beneficie a las regiones scratch grandes en las compilaciones de Linux de MSHV.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

lifecycle/confirmed

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.

Ref: #1765

Lenguaje dominante
Rust
Estrellas
4.7k
Forks
210
Merge medio
1 d 12 h
PR fusionados (30 d)
43

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de hyperlight-dev/hyperlight

Todos los issues de hyperlight-dev/hyperlight

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.