Years ago I would have this issue on my Acer desktop-- 24 GB of RAM with a hard drive, 4-core 3 GHz CPU, and swap enabled. I'd start some memory- hungry program and within seconds everything would slow to a crawl; zero mouse movement, no response to Ctrl-Alt-F2, SysRq hotkeys, or even NumLock. I'd wait 2-5 hours and give up, thinking maybe it was a fluke.
It wasn't. I switched distros and replaced the HDD with an NVMe drive, tried disabling swap and changing VM settings, switched to a low-latency kernel, and installed more RAM to no improvement. One too many Chrome tabs, one overzealous Blender render, or a single type-o in my Minecraft server properties, and I'd sooner reboot, redo all the work that was unsaved, and get a good night's rest before the kernel got around to killing processes. Maybe it was just that kernel version or motherboard or CPU? Nope. Fast-forward to today, and I'm sitting in front of a machine with 64 gigabytes of 3200 MHz RAM, an NVMe drive with read/write speeds on the order of 1000s of MB/s, and a 16-thread 4.5 GHz processor that are currently all rendered as useless to me as a misshapen lump of dusty silicon. My mistake (about two hours ago now) was running a CFD simulation with one of a few dozen relevant values set one increment too large. Imagine my surprise when I find a thread for this widely known, easily reproducible, Linux-specific torment that is not 2 years old or 5 or even 15, but has been a continual stream of experiences like mine lasting longer than I've been able to use a mouse. I don't devote time to whining on random forums about some niche feature that I think is overdue, but when everyone's computers are constantly at risk of being transformed into hot, loud bricks until somebody pulls the plug, I can't help but question how this isn't a high enough priority to get fixed within the time it takes for a babbling infant to be considered a legal adult. Today it was Linux Mint 21.1 on 5.15.0-140-generic, if specificity yields any ethos. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/159356 Title: When DMA is disabled system freeze on high memory usage Status in linux package in Ubuntu: Incomplete Status in linux package in Arch Linux: New Status in Gentoo Linux: New Bug description: I run a batch matlab job server here at my lab, running Dapper 6.06 (for the LTS). One of the users has submitted a very memory-consuming job, which successfully crashes the server. Upon closer inspection, the crash happens like this: 1. I run matlab with the given file (as an ordinary, unpriveleged user) 2. RAM usage quickly fills up 3. Once the RAM meter hits 100%, the system freezes: All SSH connections freeze up, and while switching VTs directly on the machine works, no new processes run - so one can't log in, or do anything if he is logged in. (Sometimes typing doesn't work at all) Note that the swap - while 7 gigs of it are available - is never used. (The machine has 7 gigs of RAM as well) I've tried the same on my Gutsy 32-bit box, and there was no system freezeup - matlab simply notified that the system was out of memory. However, it did this once memory was 100% in use - and still, swap didn't get used at all! (Though it is mounted correctly and shows up in "top" and "free"). So first thing's first - I'd like to eliminate the crash issue. I suppose I could switch the server to 32-bit, but I think that would be a performance loss, considering that it does a lot of heavy computation. There is no reason, however, that this should happen on a 64-bit machine anyway. Why does it? WORKAROUND: Enabling DMA in the BIOS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/159356/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
