Windows definitely stalls less in those kinds of situations. I remember running both Windows and Linux on my old 2 core 4GB RAM laptop. On Windows I could have easily swapped out almost ten GB of memory and it'd still chug along, whereas Linux would be completely unresponsive after a couple of GB of swapped out memory and require a reboot. I wonder how much the pending MGLRU patch for Linux 6.1 would help with this.
The old Windows Task Manager has code in it that killed other programs to be able to start so the user could kill more programs.
I don't know if this feature still exists in modern versions since memory has increased so much but I always found it to be neat that some developers thought about this.
Sounds like a good idea for systems that are absolutely hammered. `htop` could add a `--kill` flag, or maybe `--kill-ram` / `--kill-cpu` which would first try to kill the most ram/cpu intensive application, and then load the UI.
I've ended up in a couple of situations where servers are so hammered it takes five minutes just to get a ssh session up and running because some process took up all CPU/RAM and was barely able to do anything in the server itself. Something like that could maybe help.
David Plummer wrote the Windows Task Manager, he made a 3 part series on his YouTube channel [1]. It's a fascinating couple of videos, highly recommend to watch.
Right? It's getting worse and worse with each update.
I remember praising mac os memory management back in the days when you could just go to "Applications" folder and open everything at once without a hiccup.
Today, even rebooting with "reopen apps" option is a nightmare.
If that was the case, macOS and windows would own the server market because who would want to have a server that "freezes" under "heavy memory load". MacOS is virtually non-existent and Windows has a small share of the market and performs poorly comparison.
I linked threads on LKML that are directly relevant to this subject, about how this (system becomes nonresponsive under memory pressure) is a real problem that people really experience, with a lot of people agreeing that it is a problem and suggesting various mitigations. Most of those ideas presuppose that memory pressure leads to stalls and are about figuring out how to detect when the system is stalled and making no progress and killing processes after it has gone on for a while (often with userspace daemons). I think MGLRU is maybe getting merged in linux 6.x and will hopefully help avoid the stalls.
you linked a list of all CVEs in macOS. I don't see how this is relevant at all.
I vaguely remember Solaris had a way to prioritise focused X Window application (IA) while keeping it within time-sharing (TS) scheduling class.
Kernel thread for interactive applications in focused window would then have higher priority than background applications improving responsiveness. I am not sure what manipulated the priority, but I assume Xsun (X Window server) did it.
Ok. I got it. Literally speaking there are two (maybe more?) known bugs. Do we know how many are there for Windows and macOS? I get freezes every now and then under macOS, so there _might_ be memory management issues there as well.
My point stills stands because I believe that the bugs you posted are largely inconsequential. Bugs could be very well been patched by now (or not). My guess the fix won't uptick the % of linux in desktop or server market.
IMHO "the truth is in the pudding": if the largest share of mobile OS's is based on linux (android) and largest % in servers in again based on linux, memory management is overall good enough - otherwise the market share would have dropped considerably.
UPDATE: Revisiting the thread question... I'm barking at the wrong tree. The question wasn't about relevance and market %. Your comment is to the point.