This issue is a long time coming. I got a mini pc (Asrock Deskmini h110, i5-6400, 16gb) that I have used for a long time with Kubuntu/Kde Neon, and most of its life, it worked great. Some years ago, it started freezing, especially at Graphic intensive workload, so I thought some hardware issue and converted it into a NAS and it worked absolutely fine as well for a couple of years there too. Recently my wife needed a Windows PC to do some work, and since I had upgraded my NAS, I repurposed the same PC and installed Windows on it, and it worked absolutely fine for her too. Then I decided to check some Graphics intensive workload, like 3d benchmarking stuff, and it didn’t freeze once. I was delighted, and thought maybe I didn’t investigated the issue the first time, and the PC was fine all along. So I reinstalled Debian 13, and lo behold, the issue came back. I found out while I was using IKEA’s 3d kitchen planner. So I replaced distros, and it froze on Ubuntu and CachyOS as well. I tried switching between Wayland and X11, switched browsers, but PC freezes seconds logging into IKEA’s kitchen planner (as soon as 3d graphics are loaded). I reinstalled windows, and my wife has been designing a kitchen in IKEA’s 3d kitchen planner for over an hour now, and it hasn’t frozen once. What’s going on? How do I even investigate this?
I have reinstalled Linux and had sudo dmesg -w running, but no logs are captured before it’s frozen. I have reproduced the issue multiple times now on Linux, and not once it froze on Windows. I have also done memtests, and tried multiple disks both nvme and sata. Also have tried multiple browsers with apt and flatpaks. I really need Lemmy’s collective intelligence to help me here.
Linux is kind of dogshit at memory management unfortunately, due to a thing called overcommit it can essentially commit more memory than there actually exists on the system, cue potential for hard locks, stutters and freezing, there are some mitigations
Now the common recommendation is brute forcing the issue by making a swap partition or file, this is generally a bad idea on a modern system, due to the speed of ssds and even some fast spinning hard drives its possible for the kernel to get confused and think there’s enough memory spare where it becomes less snappy about clearing memory, often ironically making the problem worse, generally only use a swap partition if you need something else like hibernation
What should instead be done these days is setting up zram which essentially does compression of your memory in ram so that it stays clear for as long as possible, zswap does something similar but will also fallback to a swap partition soon after, the two are very similar so just setup zram on installs that dont have or need a swap partition, and setup zswap on ones that need or already have a swap partition(as they’re annoying to remove in an existing install)
But we’re not done yet because while this will buy you a lot of time there is still another massive issue at play, the linux kernel’s oom killer doesn’t generally care how full your memory is unless it starts biting into the kernel’s needs, this means it can take ages before it does anything even if everything is so overloaded where your display server has been hard frozen for 20 minutes, and since it has no real priority outside of the kernel it may force shut off vital processes first rather than secondary ones
To fix this you want a userspace oom killer that keeps in mind the entire OS and prioritises what needs to go first, many exist but if you want something that just works then EarlyOOM is great
With these mitigations in place your OS should become much less prone to freezing and stutters, if you really want a nuclear option there’s also cgroups