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

  • You-
    replied
    Originally posted by paupav View Post

    will systemd-oom integrate with selinux for that feature?
    I dont know the implementation details, just a few things I have read, but AFAIK, no. It uses cgroups and systemd confiuration files.

    A hitch being discussed in the mailing list right now is that it can only be used safely in environments where apps are launched in their own cgroup (so gnome and KDE). Others will need to adopt the same idea or avoud systemd-oomd.

    Leave a comment:


  • vladimir86
    replied
    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

    Leave a comment:


  • polarathene
    replied
    IIRC, this won't play well with a kernel using MuQSS?

    Leave a comment:


  • paupav
    replied
    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?

    Leave a comment:


  • You-
    replied
    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.

    Leave a comment:


  • CommunityMember
    replied
    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.

    Leave a comment:


  • Awesomeness
    replied
    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).

    Leave a comment:


  • wizard69
    replied
    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.

    Leave a comment:


  • ezst036
    replied
    Greatly appreciated!

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

    Leave a comment:


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

    Leave a comment:

Working...
X