Linux 7.3 mejora el rendimiento cuando se queda sin VRAM

Artículo original ↗ Discusión en Hacker News ↗

Linux kernel 7.3 introduce nueva gestión de VRAM que mejora mucho el rendimiento cuando las GPUs se quedan sin memoria de vídeo, especialmente para juegos y cargas de trabajo con mucha carga gráfica. Los comentaristas comparan esto con el comportamiento de Windows y macOS bajo presión de memoria, debaten sobre overcommit, swap y OOM killing, y señalan que Linux a menudo aún se congela o mata aplicaciones al azar salvo que se ajuste con herramientas como earlyoom o systemd-oomd. El hilo también destaca problemas de larga data con los controladores de Nvidia en Linux frente al comportamiento más fluido de AMD al pasar de VRAM a RAM del sistema, así como preocupaciones más amplias sobre fugas de memoria, capacidad de respuesta del escritorio y cómo distintas plataformas priorizan la estabilidad frente a la flexibilidad.

Reacción general al trabajo del kernel

  • El artículo es elogiado por ser una ingeniería de kernel clara y detallada, con herramientas de trazado útiles (p. ej., gpuvis, DRM tracepoints).
  • Muchos expresan entusiasmo por el enfoque de Linux 7.2/7.3 en los juegos y el rendimiento de la GPU.
  • Algunos señalan que un buen comportamiento de la VRAM está, en última instancia, limitado por el diseño del hardware (p. ej., el scanout usa solo direcciones físicas).

Juegos, sobrecompromiso de VRAM y desperdicio de recursos

  • Hay gran interés en cómo las mejoras de sobrecompromiso de VRAM ayudan a juegos que tienen muchas texturas y a menudo desperdician VRAM con recursos sobredimensionados o sin usar.
  • Los comentaristas señalan ejemplos reales de texturas enormes e innecesarias y juegos que se lanzan con un desperdicio de memoria masivo.
  • Algunos se preguntan si el kernel podría reservar siempre regiones contiguas de scanout o “desfragmentar” físicamente la VRAM moviendo páginas y actualizando las tablas de páginas; la viabilidad sigue sin estar clara.

Compute / LLM e ideas de VRAM–disco

  • Para la inferencia de LLM, la mayoría espera poco beneficio: las cargas de trabajo son más predecibles y se puede gestionar manualmente la memoria de la GPU.
  • Se habla de mover datos de GPU a NVMe como una “swap de VRAM”; en el mejor de los casos es ~4× más lento debido a los límites de los carriles PCIe, así que solo serían plausibles casos de uso de nicho.

Experiencia de GPU y escritorio en Linux frente a Windows/macOS

  • Muchos celebran las rápidas mejoras del kernel de Linux; otros señalan regresiones (p. ej., el planificador de GPU revertido) y roturas específicas de distribuciones, especialmente en distribuciones rolling.
  • Se le reconoce a Windows una compatibilidad más madura con HDR/VRR y soporte para eGPU; Linux se ve como un sistema que va alcanzando terreno, pero no universalmente superior.
  • Apple Silicon/macOS recibe críticas mixtas: buena UI de OOM y comportamiento de memoria unificada para algunos, pero otros informan de ralentizaciones persistentes después de un uso intensivo de ML/GPU.

Manejo de VRAM: NVIDIA vs AMD y Wayland

  • Varios informes indican que las GPUs AMD en Linux vuelcan sin problemas a la RAM del sistema cuando la VRAM se llena, mientras que NVIDIA bajo Linux+Wayland históricamente se bloqueaba o rechazaba asignaciones cuando se agotaba la VRAM.
  • Se vinculan errores de larga data del controlador de NVIDIA en Wayland (p. ej., fugas de memoria con KWin, falta de “shared VRAM”); muchos concluyen que AMD es actualmente la opción más segura en Linux, especialmente para Wayland y juegos.

Comportamiento de OOM, swap y ajustes

  • Hay un gran subhilo sobre Linux congelándose bajo presión de RAM frente a Windows/macOS, que siguen lentos pero vivos.
  • Las explicaciones se centran en el overcommit de Linux y el OOM killer heurístico frente al modelo de asignación más estricto de Windows.
  • Se mencionan mitigaciones: swap/zswap/zram, ajuste de MGLRU, earlyoom/systemd-oomd/nohang, configuraciones de overcommit.
  • Las opiniones divergen con fuerza: algunos dicen que “bien configurado, Linux va bien”, otros califican el comportamiento predeterminado del OOM en escritorio como un problema de larga data y hostil para el usuario.

Miscelánea

  • Aclaración de que “VRAM” (no “vRAM”) es el uso estándar; “vRAM” sugiere “RAM virtual”.
  • Breve nota agradeciendo las contribuciones de grupos subrepresentados en la ingeniería de rendimiento de bajo nivel.