Announcement

Collapse
No announcement yet.

Fedora 34 Approved To Enable Systemd-OOMD By Default For All Spins

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

  • Fedora 34 Approved To Enable Systemd-OOMD By Default For All Spins

    Phoronix: Fedora 34 Approved To Enable Systemd-OOMD By Default For All Spins

    The release of Fedora 34 this spring is now cleared to enable systemd-oomd by default for all spins in an effort to enhance the out-of-memory / memory pressure experience on Linux...

    http://www.phoronix.com/scan.php?pag...-Approved-OOMD

  • #2
    Changes/EnableSystemdOomd

    What an asinine hasty decision:
    • Can we exclude certain units from being killed?
      The proposal has been updated to include implementation of a knob to exclude units from being killed by systemd-oomd. The actual interface is to be determined
      (i.e. it's not yet implemented), but will likely be an extension of the ManagedOOM*= systemd properties.
    • How will this work if everything is in the same cgroup?
      It will not work as systemd-oomd acts on a per-cgroup level. Applications will need to spawn processes into separate cgroups (e.g. with systemd-run) or use a desktop environment (e.g. GNOME, KDE) that does this for them.
      (And if you use any obscure DE or WM you're basically fucked - your entire user session might be killed).
    earlyoomd works beautifully for all use cases, now let's replace it with something catered for enterprise and let desktop users sort it out on their own.

    Comment


    • #3
      Originally posted by birdie View Post
      Changes/EnableSystemdOomd

      What an asinine hasty decision:
      • Can we exclude certain units from being killed?
        The proposal has been updated to include implementation of a knob to exclude units from being killed by systemd-oomd. The actual interface is to be determined
        (i.e. it's not yet implemented), but will likely be an extension of the ManagedOOM*= systemd properties.
      • How will this work if everything is in the same cgroup?
        It will not work as systemd-oomd acts on a per-cgroup level. Applications will need to spawn processes into separate cgroups (e.g. with systemd-run) or use a desktop environment (e.g. GNOME, KDE) that does this for them.
        (And if you use any obscure DE or WM you're basically fucked - your entire user session might be killed).
      earlyoomd works beautifully for all use cases, now let's replace it with something catered for enterprise and let desktop users sort it out on their own.
      https://github.com/rfjakob/earlyoom/issues/8
      Birdie there are different faults that are not fixable with earlyoomd without cgroups either so the idea that it works beautifully is not right. Most of these faults result in under Linux need cgroups on processes so you in fact know what is what.

      Its not a asinine decision. Linux kernel process management without cgroups is a guess me mess on what process IDs own to what process.

      Those obscure DE/WM that cannot change to start processes in their own cgroups most likely have other issues on Linux as well due to using generic stuff that is not perfectly Linux compatible.

      Comment


      • #4
        As a dev the OOM experience inside VMs has been very painful under Ubuntu 18.04.

        does anyone have a good article explaining how it currently work there and and OOM events might be different on fedora?

        Comment


        • #5
          Originally posted by Markopolo View Post
          As a dev the OOM experience inside VMs has been very painful under Ubuntu 18.04.

          does anyone have a good article explaining how it currently work there and and OOM events might be different on fedora?
          Try https://engineering.fb.com/2018/07/1...ineering/oomd/

          Comment


          • #6
            I sure hope it works better than systemd-resolved.service because there is nothing that can't turn into an 8 hour outage.

            Comment

            Working...
            X