Usa la VRAM de tu GPU Nvidia como espacio de swap en Linux
Usar la VRAM de una GPU Nvidia como espacio de swap en Linux se plantea como una forma de recuperar memoria de vídeo ociosa en máquinas con RAM limitada y no ampliable, especialmente portátiles. Quienes comentan lo ven como un truco ingenioso y de nicho que puede reducir el desgaste del SSD, pero señalan que las implementaciones actuales en espacio de usuario y basadas en NBD están muy lejos de saturar el ancho de banda de PCIe o VRAM y pueden complicar la gestión de energía o las cargas de trabajo de gaming. El intercambio más amplio revisa cuándo el swap es beneficioso en absoluto, cómo funcionan las estrategias de paginación del kernel y por qué la memoria de la GPU no se puede tratar sin más como RAM del sistema normal.
Motivación y casos de uso
- Pensado para máquinas con RAM limitada y no ampliable, pero con VRAM Nvidia relativamente grande y a menudo inactiva (por ejemplo, portátiles en modo de GPU híbrida, sobremesas con grandes tarjetas de gaming/IA).
- Permite que la VRAM no usada actúe como swap en lugar de escribir en SSD, lo que potencialmente ahorra desgaste de la memoria flash y aprovecha memoria que de otro modo se desperdiciaría.
- Se considera especialmente atractivo cuando las cargas de trabajo (juegos frente a “productividad” / uso intensivo de RAM) no son concurrentes, de modo que la VRAM puede reutilizarse cuando la GPU está inactiva.
Preocupaciones sobre rendimiento e implementación
- El rendimiento reportado (~1,3 GB/s en una laptop RTX 3070) está muy por debajo del ancho de banda teórico de PCIe/VRAM.
- El hilo atribuye esto a:
- Implementación en espacio de usuario usando NBD, que se sabe que es relativamente lenta.
- Copias extra mediante un buffer de rebote y muchos cambios de contexto kernel/usuario por cada página de 4K.
- Profundidad de cola limitada y mala coalescencia de solicitudes con NBD.
- Sobrecarga de compresión de ZRAM (aunque algunos creen que esto es menor).
- El swap a NVMe se describe como una ruta altamente optimizada, sin copia y basada en DMA, que puede ser más rápida en la práctica.
- Sugerencias: pasar a ublk o a un controlador de bloque personalizado en el kernel para reducir la sobrecarga y aumentar la concurrencia.
Límites de hardware y arquitectura
- La VRAM no puede simplemente añadirse a la RAM del sistema porque la mayoría de las GPU de escritorio no son coherentes en caché con la CPU y deben asignarse sin caché o con write-combining, lo que las hace muy lentas como “RAM” real.
- Las GPU de centro de datos y los futuros dispositivos estilo CXL pueden ofrecer coherencia, pero la latencia sigue siendo mucho mayor que la de la DRAM.
- Existen enfoques históricos y alternativos (MTD/phram, vramfs, ramdisks basados en OpenCL/Vulkan, Windows GpuRamDrive).
Semántica del swap y desgaste del SSD
- Algunos ven el swap en VRAM como una forma de evitar el desgaste del SSD; otros argumentan que el uso real de swap normalmente no acorta de forma significativa la vida útil del SSD.
- Debate más amplio sobre el swap:
- Algunos configuran un swap grande (a menudo para suspender a disco) y dependen de él para evitar un OOM abrupto.
- Otros prefieren poco o ningún swap, y tratan el swapping intenso como equivalente a un sistema “muerto”.
- Una visión: la función principal del swap es la reclamación justa entre memoria anónima y respaldada por archivos, no una RAM de emergencia.
Usabilidad, riesgos y energía
- Existe la preocupación de que usar VRAM como swap pueda:
- Impedir el power-gating de la GPU, perjudicando la duración de la batería en portátiles.
- Competir con cargas gráficas o de cómputo y provocar fallos si la VRAM se agota (especialmente en compositores dinámicos de Wayland).
- Se desea habilitar y deshabilitar dinámicamente el swap de VRAM en función de la presión sobre la GPU, pero no está resuelto del todo; se señala como un área pendiente.
- La preocupación clásica de estilo microkernel (que el daemon de swap necesite paginarse a sí mismo) se aborda manteniendo sus páginas no intercambiables o fijadas.