Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • This post focuses on performance, but what about crashing due to apps seeing no RAM available to allocate once VRAM is filled up?

    I remember having this problem when I used an NVIDIA 750 Ti with 2 GB of memory. Just opening a few Firefox or Ghostty terminals (both are GPU accelerated) would result in those apps crashing or not being able to render their contents. Sometimes the compositor would crash or become unstable too (kwin, niri, etc.). I had to reboot every few hours. Complete system instability.

    This problem only happened with Wayland, when I switched to X windows these problems went away.

    Since then I switched to an AMD RX 480 (8 GB) GPU and never had an issue here with Wayland, if GPU memory gets full, system memory gets seamlessly used instead. It felt like with the NVIDIA card, it never allocated back to system memory if no VRAM was available. This was only a problem on Linux since that same NVIDIA card was fine in Windows for 10+ years with zero issues related to instability around VRAM allocation.

    Tons of people reported the same issue on Linux on NVIDIA's forums for years.

    I wrote a lot more details and recorded demo videos around 9 months ago here https://nickjanetakis.com/blog/gpu-memory-allocation-bugs-wi..., but since then a lot of these things have been resolved from switching over to AMD.

  • Great article! I share the same hunch as the author does; when allocating memory ultimately the application itself is in the best position to inform the kernel about the desired stickiness to VRAM. The best a kernel can do is guessing.

    As a side note, it strikes me how much we owe to young trans people for low level performance engineering.

  • I'm mostly excited for the VRAM savings from apps and games which have loads of unused or super rarely used textures.

    Game developers often aren't super careful with this stuff, and there could be literal gigabytes of data which isn't used at all.

  • Gosh, 7.2 literally just dropped with a bunch of awesome of performance/gaming related improvements (large folios, cache-aware scheduling, improved MGLRU reclaiming, Fair GPU Scheduler etc)... and I already can't wait for 7.3 to come out.

    Meanwhile in the Windows world, users hate updates... Like I genuinely can't think of a single instance that made users exclaim, "oh boy I just can't wait for the next Patch Tuesday!".

  • I'll be the one to ask the obvious question:

    What does this mean for compute workloads? Specifically, LLM inference.

    Does it mean anything at all, or is this purely a games-thing?

  • Great article. I find that I learn something every time I read a post about linux kernel work.

    I guess an LRU with priority would handle VRAM for games pretty decently without going getting too application specific.

    What about VRAM to Disk specifically NVME, would direct to disk be feasible for large workloads, I know it is used for streaming in assets directly via. PCIE, but i wonder how the performance would be on compute workloads running with NVME as a swap for GPU VRAM.

  • I hope there will be an update where when my RAM gets full my PC doesn't freeze and becomes unusable... I remember that Linux and Windows do this in different ways and Windows doesn't have the problem.
  • This seems like an impressive improvement, and I'm looking forward to it eventually being upstreamed. Though unfortunately I'm on Nvidia right now, and have been struggling with vram. They don't seem to support any kind of paging at all.

    I am curious about the bit on virtual memory fragmentation. Would it make sense for the kernel to occasionally defragment that memory in place? I assume that would create a noticeable hitch, but might improve performance otherwise and allow for some applications to just fit in.

Explore Birbla archives

Linux 7.3 improves performance when running out of vRAM · Birbla