5 ms·

How Linux freezes under high memory usage, Mac OS and Windows both handle such situations well without requiring a hard reboot.

atmosx 4y ago
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.
- rrss 4y ago
  by "freezes", 'deeter72 almost certainly means that the user interface becomes unresponsive, which is not relevant for servers. windows has policies that prioritize maintaining user interface and foreground app responsiveness.
  - atmosx 4y ago
    I guessed as much but I stand by my statement… If there was a serious problem, we would know by now.
    - rrss 4y ago
      We do know by now, which is why the LKML thread I linked is titled "the elephant in the room."
      - atmosx 4y ago
        original answer: 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.
        rrss 4y ago
        > if the largest share of mobile OS's is based on linux (android) Android has had a variety of downstream patches over the last 5-10 years to address this problem. ChromeOS too.
  - rrss 4y ago
    see also: https://lore.kernel.org/all/d9802b6a-949b-b327-c4a6-3dbca485ec20@gmx.com/ https://lore.kernel.org/all/d9802b6a-949b-b327-c4a6-3dbca485... https://lore.kernel.org/all/20211130201652.2218636d@mail.inbox.lv/ https://lore.kernel.org/all/20211130201652.2218636d@mail.inb...
    - atmosx 4y ago
      https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=macOS+ https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=macOS+ So? What’s the point here?
      - rrss 4y ago
        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.
        atmosx 4y ago
        > [...] is a real problem that people really experience, with a lot of people agreeing that it is a problem and suggesting various mitigations [...] tl;dr: I believe you are overblowing the importance of the bugs. In the bigger scheme of things they're more likely inconsequential. (see my other reply for more)
        rrss 4y ago
        These links are not just two simple bugs. The first link is a report that the system becomes nonresponsive under memory pressure and a discussion of that report. In that thread, there was not really any agreement about whether this was a bug, let alone what the bug was, or what the fix would be. The second wasn’t a bug at all, it was a patch proposed set of knobs to allow users to avoid the problem.
  - ivlad 4y ago
    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.
    - worthless-trash 4y ago
      I believe that this absolutely could be done with ebpf setting schedule priority. A small daemon looking at the front-running window and you're there. https://lwn.net/Articles/873244/ https://lwn.net/Articles/873244/
- pjmlp 4y ago
  It is more a matter of paying for licenses than anything else.
SuperSandro2000 4y ago
Windows freezes, too and if you are a heavy multitasker with a program that hogs memory and you are not carefully it can happen wow frequently
- _piif 4y ago
  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.
- foepys 4y ago
  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.
  - capableweb 4y ago
    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.
  - pjmlp 4y ago
    Basically kill -9
  - greenstatic 4y ago
    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. [1] https://www.youtube.com/watch?v=f8VBOiPV-_M https://www.youtube.com/watch?v=f8VBOiPV-_M
moxvallix 4y ago
Use earlyoom: https://github.com/rfjakob/earlyoom https://github.com/rfjakob/earlyoom.
m00x 4y ago
Mac OS absolutely freezes too. It happened to me just a few days ago and I had to hard reboot.
- worthless-trash 4y ago
  Ask a mac zealot this and they will deny it ever happening.
  - treeman79 4y ago
    Mac user for 15 years. Happened to me maybe a dozen times.
    - ungamedplayer 4y ago
      You must not be a Mac zealot
- foverzar 4y ago
  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.

atmosx 4y ago

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.

rrss 4y ago
by "freezes", 'deeter72 almost certainly means that the user interface becomes unresponsive, which is not relevant for servers. windows has policies that prioritize maintaining user interface and foreground app responsiveness.
- atmosx 4y ago
  I guessed as much but I stand by my statement… If there was a serious problem, we would know by now.
  - rrss 4y ago
    We do know by now, which is why the LKML thread I linked is titled "the elephant in the room."
    - atmosx 4y ago
      original answer: 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.
      - rrss 4y ago
        > if the largest share of mobile OS's is based on linux (android) Android has had a variety of downstream patches over the last 5-10 years to address this problem. ChromeOS too.
- rrss 4y ago
  see also: https://lore.kernel.org/all/d9802b6a-949b-b327-c4a6-3dbca485ec20@gmx.com/ https://lore.kernel.org/all/d9802b6a-949b-b327-c4a6-3dbca485... https://lore.kernel.org/all/20211130201652.2218636d@mail.inbox.lv/ https://lore.kernel.org/all/20211130201652.2218636d@mail.inb...
  - atmosx 4y ago
    https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=macOS+ https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=macOS+ So? What’s the point here?
    - rrss 4y ago
      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.
      - atmosx 4y ago
        > [...] is a real problem that people really experience, with a lot of people agreeing that it is a problem and suggesting various mitigations [...] tl;dr: I believe you are overblowing the importance of the bugs. In the bigger scheme of things they're more likely inconsequential. (see my other reply for more)
        rrss 4y ago
        These links are not just two simple bugs. The first link is a report that the system becomes nonresponsive under memory pressure and a discussion of that report. In that thread, there was not really any agreement about whether this was a bug, let alone what the bug was, or what the fix would be. The second wasn’t a bug at all, it was a patch proposed set of knobs to allow users to avoid the problem.
- ivlad 4y ago
  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.
  - worthless-trash 4y ago
    I believe that this absolutely could be done with ebpf setting schedule priority. A small daemon looking at the front-running window and you're there. https://lwn.net/Articles/873244/ https://lwn.net/Articles/873244/
pjmlp 4y ago
It is more a matter of paying for licenses than anything else.

SuperSandro2000 4y ago

Windows freezes, too and if you are a heavy multitasker with a program that hogs memory and you are not carefully it can happen wow frequently

_piif 4y ago
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.
foepys 4y ago
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.
- capableweb 4y ago
  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.
- pjmlp 4y ago
  Basically kill -9
- greenstatic 4y ago
  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. [1] https://www.youtube.com/watch?v=f8VBOiPV-_M https://www.youtube.com/watch?v=f8VBOiPV-_M

moxvallix 4y ago

Use earlyoom: https://github.com/rfjakob/earlyoom https://github.com/rfjakob/earlyoom.

m00x 4y ago

Mac OS absolutely freezes too. It happened to me just a few days ago and I had to hard reboot.

worthless-trash 4y ago
Ask a mac zealot this and they will deny it ever happening.
- treeman79 4y ago
  Mac user for 15 years. Happened to me maybe a dozen times.
  - ungamedplayer 4y ago
    You must not be a Mac zealot
foverzar 4y ago
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.