Announcement

Collapse
No announcement yet.

Fedora 34 Planning To Make Use Of Systemd-OOMD To Improve Low Memory Experience

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

  • Fedora 34 Planning To Make Use Of Systemd-OOMD To Improve Low Memory Experience

    Phoronix: Fedora 34 Planning To Make Use Of Systemd-OOMD To Improve Low Memory Experience

    At the end of November systemd 247 released with the new Out-of-Memory Daemon (systemd-oomd) and for the Fedora 34 release next year that will likely be enabled by default for all spins...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Finally, the solution for end-users to the long-standing problem about memory management when RAM is saturated so to avoid the system stalls. 👏 🤗 👍🏻 💪 💖

    Comment


    • #3
      Greatly appreciated!

      I've seen what happens on systems when you reach the max. It isn't pretty.

      Comment


      • #4
        interesting! I'm not sure this will kick in considering my usage but honestly it would have been huge in the old days of low memory machines.

        Comment


        • #5
          Originally posted by Azrael5 View Post
          Finally, the solution for end-users to the long-standing problem about memory management when RAM is saturated so to avoid the system stalls. 👏 🤗 👍🏻 💪 💖
          What are you talking about? Fedora already uses EarlyOOM on desktops.

          This proposal is to switch defaults to a different mechanism (but doesn't outline why systemd-oomd would be better than EarlyOOM).

          Comment


          • #6
            Originally posted by Awesomeness View Post
            What are you talking about? Fedora already uses EarlyOOM on desktops.

            This proposal is to switch defaults to a different mechanism (but doesn't outline why systemd-oomd would be better than EarlyOOM).
            It would (in theory) better integrate with cgroups and systemd unit lifetime, and (perhaps) make better decisions as to when things have gone bad, and which things to terminate first.

            As with all such attempts to deal with out-of-memory conditions, the results of what to do will work well for some, and badly for others.

            At the time of enabling/defaulting to earlyoom there were already discussions on the various email lists that systemd-oomd appeared that it would likely end up being the preferred implementation, but that it was not yet ready for prime time.

            Comment


            • #7
              AFAIK it has a mechanism for apps and the system to declare which apps can be terminated. You can declare which programs can and should be terminated and which shouldnt.

              As it terminates a whole cgroup, it wont leave dangling threads for processes that have created other processes that may be missed with the other method.

              Comment


              • #8
                Originally posted by You- View Post
                AFAIK it has a mechanism for apps and the system to declare which apps can be terminated. You can declare which programs can and should be terminated and which shouldnt.

                As it terminates a whole cgroup, it wont leave dangling threads for processes that have created other processes that may be missed with the other method.
                will systemd-oom integrate with selinux for that feature?

                Comment


                • #9
                  IIRC, this won't play well with a kernel using MuQSS?

                  Comment


                  • #10
                    That is such bullshit. We all should know the best memory usage is achieved with BasicLinux. Have that puppy run on a Pentium 1 with 16 mb of RAM and 166Mhz. GUI included! And no SystemD

                    Comment

                    Working...
                    X