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

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

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

    For months there has been many different discussions over the Linux desktop's poor performance when under memory pressure / out-of-memory type situations. That has resulted in some upstream work so far like GNOME GLib's GMemoryMonitor as well as discussions by distribution vendors about what solutions they could enable today to help the low memory situations. Fedora 32 could begin shipping and using EarlyOOM by default to help in this area...

    http://www.phoronix.com/scan.php?pag...fault-EarlyOOM

  • #2
    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.

    Comment


    • #3
      Why not disable paging executable code out at all and making it resident on memory at almost all times? Because this may be the cause according to a few users in a former thread.

      Comment


      • #4
        Originally posted by k1e0x View Post
        Wait.. I know.. systemd-oom-bandaid.
        Hateword #1 of the past ten years. I bet twenty more to come. 1.3 mio lines for /dev/null

        Comment


        • #5
          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.
          I actually think systemd is the perfect place for an oom killer.

          Comment


          • #6
            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.
            It's funny you mention "you know who". Because on our databases when there's a runaway or something that causes the OOM-killer to happen, we lose pieces of systemd. And the only way you can restart systemd is with systemd (which is now non-operational). We end up having to bring our systems down hard and reboot to fix. This is all on CentOS 7.

            Comment


            • #7
              Originally posted by cjcox View Post

              It's funny you mention "you know who". Because on our databases when there's a runaway or something that causes the OOM-killer to happen, we lose pieces of systemd. And the only way you can restart systemd is with systemd (which is now non-operational). We end up having to bring our systems down hard and reboot to fix. This is all on CentOS 7.
              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.

              Comment


              • #8
                Fedora 32 is going to be exciting. If they provide Gnome optimization as well it will be awesome.

                Comment


                • #9
                  Originally posted by tildearrow View Post
                  Why not disable paging executable code out at all and making it resident on memory at almost all times? Because this may be the cause according to a few users in a former thread.
                  The problem is those huge dynamic libraries.

                  Comment


                  • #10
                    Originally posted by Britoid View Post

                    I actually think systemd is the perfect place for an oom killer.
                    Not sure that systemd (or any init system) really have more information to make a better decision than the kernel.

                    To me a kind of ok solution would be on a gui desktop to pop up a dialog informing the user about the situation and asking which process to kill (if you can get pass the chicken and egg to actually get something displayed)

                    Comment

                    Working...
                    X