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 might be in the minority here, but some of the latest Windows updates that dropped in the Insider channel are really cool, and I'm excited to see those coming to main.
They seem to be focused on performance improvements because of the MacBook Neo pressure and RAM crisis, but right now, I'm mostly excited for the right-click menu and taskbar improvements. You can already do this with third-party software, but it's not the best experience unfortunately.
Are they finally going to fix the issue of having introduced a second right click menu that forces me to click “show more options” literally every single time I want to do anything?
Fair point, the old school service packs and hotfix rollups were cool. But I think that sort of enthusiasm towards updates ended with XP, at least it did for me, because I switched to Linux permanently after Windows 7 came out.
XP was indeed when I stopped caring about Windows updates, SP2 was a huge deal - after that they where either "eh" or actively things I didn't want.
To be honest I think the reason I stopped care was more that I started using Linux as an OS in the 90's and over time more and more of my computing life was on Linux (except gaming) so by 2004 (or a little earlier) Windows was just for games.
Being able to preview media files directly in the preview pane of explorer was mind blowing to me. This feature alone made me love ME, let alone the interface customisation it allowed.
Such great work!
Happens quiet regularly I hit a game just realizing seconds later I haven't shut down my local LLM yet. At least punishment will be less harsh. Lets see, maybe some games in window mode will just work fine.
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.
Your last sentence sums it all: AMD is the only serious option on Linux. Not perfect, but far better than Nvidia, thanks to their open drivers that anyone (and especially Valve) can improve.
I gave myself 32GB of swap since SSDs are quite fast and the pages sent to disk seem to intelligently be rarely referenced ones. Feels amazing to run 4 VMs and 12 Claude Code instances on my mid tier hardware
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.
Me too, but you can improve the behavior yourself too. It's been an issue with desktop linux and the default settings for a long time. You could maybe tune OOM killer settings, but another option is to use a package like earlyoom: https://man.archlinux.org/man/earlyoom.1.en
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.
Of course. These are the people that the industry needs who understands proper performance-level engineering.
The commits they authored in [0] match and all of what they have mentioned in the article and this is how you know the author knows exactly what they are talking about and have explained it well.
Puts all the vibe-coders, and the so-called "AI Engineers" to shame. I know that if I ask about the basic system design of amdgpu and drm (direct rendering manager) infrastructure in Linux, a small handful will be able to explain it without using AI or googling.
I worked on a PC/PS4/Xbox One game once. I wish I remembered more details, but at some point when looking at memory usage I found a 2048x2048 (or something like that) texture for something on a character. This texture was never anywhere near occupying the full screen. It got downsized once I told one of the artists, but I wouldn't be surprised if some games are inadvertently shipping with that kind of waste.
The release version of City Skylines 2 had enormous issues due to this problem. Some tiny details, like a pile of wood behind a shed, had ridiculous amount of pixels. I do believe that should be pretty much fixed in that title nowadays, however.
If you have model layers/experts that reside in CPU RAM, it's generally better to do that part of inference on the CPU than pay the cost of shipping them over to the GPU. LLM inference is generally bottlenecked by data-movement, not compute. There may be a limited exception for prefill or perhaps decode of very wide batches, where shuffling the data around may be justified.
I doubt it makes much of a difference, and you can always manually manage what data lives in the GPU when if you 100% have to overcommit. Games have a much larger and more diverse set of objects in the VRAM, and their usage is less predictable, so manual scheduling of the memory is infeasible typically.
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.
This is a nice blog and it makes sense to me now. As a gamer and linux user myself, I've previously had to do tweaks and go-arounds without really understanding what was going on behind the scenes. :)
Great writeup, gpuvis looks particularly interesting and glad the kernel is providing tracepoints for performance events.
> Not only does the display hardware like scanned-out images to be in VRAM, it also completely skips past the GPU’s virtual memory architecture and works with physical addresses exclusively.
Well there's your problem. Only so smart your memory management can be when you have to pay the cost of doing it manually. Although presumably this only applies to a small fraction of the VRAM?
> Although presumably this only applies to a small fraction of the VRAM?
They did mention they saw 4GiB of eviction for a single 32MiB scan out image.
So while I would call the image allocation small, it seems to cause an avalanche of evictions. Amplified by the fact that each frame has one of these images, though I expect subsequent frames might have a better chance of already fitting into evicted space.
What I don't exactly understand is: doesn't it make sense to always reserve the contiguous physical memory for this case and not allow anything else to be put in it?
Or alternatively, instead of evicting it all, can you move the data around in physical memory while updating the page table, so that you can clear a large enough continuous block of physical memory?
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!".
[1] Linux 7.2 Reverts DRM Scheduler Change After Serious GPU Regressions: https://www.linuxjournal.com/content/linux-72-reverts-drm-sc...
Ah, didn't know that was reverted. Cheers for the link.
I personally am very excited for the upcoming Windows 11 update which will allow users to move the taskbar to any edge of their screen.
I might be in the minority here, but some of the latest Windows updates that dropped in the Insider channel are really cool, and I'm excited to see those coming to main.
Do you have a link for a list of these changes. I am curious.
Sure. The Insider blog tends to be pretty up-to-date: https://blogs.windows.com/windows-insider/
They seem to be focused on performance improvements because of the MacBook Neo pressure and RAM crisis, but right now, I'm mostly excited for the right-click menu and taskbar improvements. You can already do this with third-party software, but it's not the best experience unfortunately.
Are they finally going to fix the issue of having introduced a second right click menu that forces me to click “show more options” literally every single time I want to do anything?
Run (as Administrator) in a terminal
Should restore the old right click menu (it did last time I used it at any rate).So much of windows 11 configuration is removing things you never asked for and putting things back.
Source: https://learn.microsoft.com/en-us/answers/questions/2287432/...
Didn't we eagerly await on updates in the good old days of Windows?
Fair point, the old school service packs and hotfix rollups were cool. But I think that sort of enthusiasm towards updates ended with XP, at least it did for me, because I switched to Linux permanently after Windows 7 came out.
XP was indeed when I stopped caring about Windows updates, SP2 was a huge deal - after that they where either "eh" or actively things I didn't want.
To be honest I think the reason I stopped care was more that I started using Linux as an OS in the 90's and over time more and more of my computing life was on Linux (except gaming) so by 2004 (or a little earlier) Windows was just for games.
I never did. I did wait eagerly for new .NET releases, though.
The only Windows update that made me “eagerly await” is the Windows XP SP2.
And what an update it was.
I still remember how Windows ME looked at first, the feeling of something better. That didn't last long
Being able to preview media files directly in the preview pane of explorer was mind blowing to me. This feature alone made me love ME, let alone the interface customisation it allowed.
Windows 7 was pretty neat.
....No. And those were not good days, unless your definition is fun is reinstalling OS
Back when updates were add on packs like Plus! they were very exciting
https://en.wikipedia.org/wiki/Microsoft_Plus!
Such great work! Happens quiet regularly I hit a game just realizing seconds later I haven't shut down my local LLM yet. At least punishment will be less harsh. Lets see, maybe some games in window mode will just work fine.
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.
Your last sentence sums it all: AMD is the only serious option on Linux. Not perfect, but far better than Nvidia, thanks to their open drivers that anyone (and especially Valve) can improve.
I gave myself 32GB of swap since SSDs are quite fast and the pages sent to disk seem to intelligently be rarely referenced ones. Feels amazing to run 4 VMs and 12 Claude Code instances on my mid tier hardware
Swap doesn't help in this case.
It's GPU drivers freaking out when they run out of VRAM, but it might only be specific to NVIDIA cards since AMD seems to handle this better.
But, if it's driver specific that means it could be fixed at the kernel level I suppose, especially since Windows handles it seamlessly.
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.
Me too, but you can improve the behavior yourself too. It's been an issue with desktop linux and the default settings for a long time. You could maybe tune OOM killer settings, but another option is to use a package like earlyoom: https://man.archlinux.org/man/earlyoom.1.en
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.
Of course. These are the people that the industry needs who understands proper performance-level engineering.
The commits they authored in [0] match and all of what they have mentioned in the article and this is how you know the author knows exactly what they are talking about and have explained it well.
Puts all the vibe-coders, and the so-called "AI Engineers" to shame. I know that if I ask about the basic system design of amdgpu and drm (direct rendering manager) infrastructure in Linux, a small handful will be able to explain it without using AI or googling.
[0] https://gitlab.freedesktop.org/pixelcluster/kernel/-/commits...
They'll get old soon enough.
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.
I worked on a PC/PS4/Xbox One game once. I wish I remembered more details, but at some point when looking at memory usage I found a 2048x2048 (or something like that) texture for something on a character. This texture was never anywhere near occupying the full screen. It got downsized once I told one of the artists, but I wouldn't be surprised if some games are inadvertently shipping with that kind of waste.
The release version of City Skylines 2 had enormous issues due to this problem. Some tiny details, like a pile of wood behind a shed, had ridiculous amount of pixels. I do believe that should be pretty much fixed in that title nowadays, however.
Well written and very informative. I am glad we have these enthusiastic people around for Linux kernel development!
Enthusiasm seems proportional to the number of exclamation marks (28)! (:
I'm sure Linus will insult them into indifference
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?
If you have model layers/experts that reside in CPU RAM, it's generally better to do that part of inference on the CPU than pay the cost of shipping them over to the GPU. LLM inference is generally bottlenecked by data-movement, not compute. There may be a limited exception for prefill or perhaps decode of very wide batches, where shuffling the data around may be justified.
I doubt it makes much of a difference, and you can always manually manage what data lives in the GPU when if you 100% have to overcommit. Games have a much larger and more diverse set of objects in the VRAM, and their usage is less predictable, so manual scheduling of the memory is infeasible typically.
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.
> but i wonder how the performance would be on compute workloads running with NVME as a swap for GPU VRAM.
4x as slow in absolute best case, NVMe drives have 4 PCIe lanes usually
This is a nice blog and it makes sense to me now. As a gamer and linux user myself, I've previously had to do tweaks and go-arounds without really understanding what was going on behind the scenes. :)
Great writeup, gpuvis looks particularly interesting and glad the kernel is providing tracepoints for performance events.
> Not only does the display hardware like scanned-out images to be in VRAM, it also completely skips past the GPU’s virtual memory architecture and works with physical addresses exclusively.
Well there's your problem. Only so smart your memory management can be when you have to pay the cost of doing it manually. Although presumably this only applies to a small fraction of the VRAM?
> Although presumably this only applies to a small fraction of the VRAM?
They did mention they saw 4GiB of eviction for a single 32MiB scan out image.
So while I would call the image allocation small, it seems to cause an avalanche of evictions. Amplified by the fact that each frame has one of these images, though I expect subsequent frames might have a better chance of already fitting into evicted space.
What I don't exactly understand is: doesn't it make sense to always reserve the contiguous physical memory for this case and not allow anything else to be put in it?
Or alternatively, instead of evicting it all, can you move the data around in physical memory while updating the page table, so that you can clear a large enough continuous block of physical memory?