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!".

• zekrioca

  today at 10:49 AM

  [1] Linux 7.2 Reverts DRM Scheduler Change After Serious GPU Regressions: https://www.linuxjournal.com/content/linux-72-reverts-drm-sc...

  • d3Xt3r

    today at 10:54 AM

    Ah, didn't know that was reverted. Cheers for the link.

• alt227

  today at 11:15 AM

  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.

  • HugoTea

    today at 11:26 AM

    Ah it'll be just like 2015 again

• timpera

  today at 10:29 AM

  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.

  • dainank

    today at 10:30 AM

    Do you have a link for a list of these changes. I am curious.

    • timpera

      today at 10:37 AM

      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.

      • chongli

        today at 10:51 AM

        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?

        • noir_lord

          today at 10:59 AM

          Run (as Administrator) in a terminal

            reg.exe add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve
          

          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/...

• toredash

  today at 10:01 AM

  Didn't we eagerly await on updates in the good old days of Windows?

  • d3Xt3r

    today at 10:14 AM

    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.

    • noir_lord

      today at 11:01 AM

      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.

  • a012

    today at 10:07 AM

    The only Windows update that made me “eagerly await” is the Windows XP SP2.

    • toredash

      today at 10:09 AM

      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

      • alt227

        today at 11:18 AM

        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.

    • patrickmcnamara

      today at 10:28 AM

      Windows 7 was pretty neat.

  • christophilus

    today at 11:11 AM

    I never did. I did wait eagerly for new .NET releases, though.

  • PunchyHamster

    today at 10:44 AM

    ....No. And those were not good days, unless your definition is fun is reinstalling OS

    • alt227

      today at 11:16 AM

      Back when updates were add on packs like Plus! they were very exciting

      https://en.wikipedia.org/wiki/Microsoft_Plus!

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.

• kalaksi

  today at 11:09 AM

  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

• zozbot234

  today at 11:07 AM

  [dead]

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.

• flaburgan

  today at 11:18 AM

  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.

• OsrsNeedsf2P

  today at 11:13 AM

  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

  • nickjj

    today at 11:18 AM

    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?

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.

• rvz

  today at 10:38 AM

  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...

• eru

  today at 10:38 AM

  They'll get old soon enough.

• weird-eye-issue

  today at 10:27 AM

  [flagged]

  • exceptione

    today at 10:34 AM

    Just an observation.

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.

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.

• FartyMcFarter

  today at 10:51 AM

  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.

  • yxhuvud

    today at 10:58 AM

    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!

• cubefox

  today at 9:16 AM

  Enthusiasm seems proportional to the number of exclamation marks (28)! (:

• bcjdjsndon

  today at 10:15 AM

  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?

• zozbot234

  today at 11:14 AM

  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.

• skew-aberration

  today at 9:28 AM

  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.

Also Apple M3 support

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.

• PunchyHamster

  today at 10:55 AM

  > 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?

• NekkoDroid

  today at 9:31 AM

  > 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?

  • jojomodding

    today at 10:39 AM

    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?

[dead]