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.
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.
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.
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 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 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?
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. :)
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.
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.
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.
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
Windows 7 was pretty neat.
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.
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.
They'll get old soon enough.
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.
[0] https://gitlab.freedesktop.org/pixelcluster/kernel/-/commits...
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
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'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?
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 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?
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. :)