Announcement

Collapse
No announcement yet.

Fedora 32 Looking At Using EarlyOOM By Default To Better Deal With Low Memory Situations

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    Originally posted by k1e0x View Post
    Why not just fix the kernel's OOM killer? Other OS's don't hang up like Linux does in that situation.. Wait.. I know.. systemd-oom-bandaid.
    there are some hints to your question on the earlyoom github page: https://github.com/rfjakob/earlyoom
    It is hard for the kernel to know what to kill. You are doing a disservice to the kernel devs if you think it is easy.

    As for other OS: I have stress tested win 10 and ubuntu + earlyoom (2GB, no swap, load 100 tabs in Chrome), and windows 10 does not do very well; most of the time the VM just crashed, sometimes chrome died (all of it). earlyoom kills tabs, the machine stays responsive. In other words, Linux with earlyoom is a much better experience than Windows 10, in my testing.

    Also, there is a new project, nohang, which is more sophisticated. It provides desktop notifications out of the box, and it can use the new memory presssure KPIs and messages from zram to give more warning about low memory. In default settings, it acts very much like earlyoom (but with desktop notifications about low memory). Desktop Linux needs a user space killer, the kernel devs have made that clear, and we have earlyoom and a newer one, nohang, plus gnome is building in notification support. Right now, anyone who complains about OOM deadlocks should install earlyoom, problem solved.

    The kernel killer only fails sometimes, too; there is a lot of exaggeration about how bad it is. I run countless 2GB linux servers, and I never get OOM deadlocks. Obviously it can happen, otherwise facebook wouldn't have added pressure stall KPIs to the kernel, but it is rare.

    Comment


    • #72
      Originally posted by Britoid View Post

      systemd should remain operational as long as pid 1 is still there, which should never be killed or swapped out.

      anything else sounds like a kernel bug.
      All I know is that it's "running" but you can't use it, communicate with it in any way shape or form. New services cannot stop, existing services cannot be shutdown. You can't "reboot". You have to hard kill the box. Call that whatever you want.

      Comment


      • #73
        Originally posted by timrichardson View Post

        there are some hints to your question on the earlyoom github page: https://github.com/rfjakob/earlyoom
        It is hard for the kernel to know what to kill. You are doing a disservice to the kernel devs if you think it is easy.

        As for other OS: I have stress tested win 10 and ubuntu + earlyoom (2GB, no swap, load 100 tabs in Chrome), and windows 10 does not do very well; most of the time the VM just crashed, sometimes chrome died (all of it). earlyoom kills tabs, the machine stays responsive. In other words, Linux with earlyoom is a much better experience than Windows 10, in my testing.

        Also, there is a new project, nohang, which is more sophisticated. It provides desktop notifications out of the box, and it can use the new memory presssure KPIs and messages from zram to give more warning about low memory. In default settings, it acts very much like earlyoom (but with desktop notifications about low memory). Desktop Linux needs a user space killer, the kernel devs have made that clear, and we have earlyoom and a newer one, nohang, plus gnome is building in notification support. Right now, anyone who complains about OOM deadlocks should install earlyoom, problem solved.

        The kernel killer only fails sometimes, too; there is a lot of exaggeration about how bad it is. I run countless 2GB linux servers, and I never get OOM deadlocks. Obviously it can happen, otherwise facebook wouldn't have added pressure stall KPIs to the kernel, but it is rare.
        Good, I'm glad to do a disservice to them. It's broken.

        The problem isn't avoiding the situation before it happens.
        the problem is also not choosing what to kill. That might be nice, but that's not the issue here.

        It's that the existing kernel oom killer doesn't work and hangs the system.

        Comment

        Working...
        X