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

  • #51
    Linux has nasty problem of paging everything out on disk IO. My dev system has 32GiB RAM, copying somewhat around 100GiB from one HDD to another via NTFS-3g after half a hour made system barely usable, it still had considirable amount of free and usable mem (around 16GB), but desktop processes have been paged out.

    Comment


    • #52
      Originally posted by birdie View Post
      We need a solution which works without user intervention. The kernel could be the best place for this feature but kernel developers seem not to care about this issue as much as it's crucial and now we already have at least four user space daemons for the task.
      Four???? Can you point me to them? (just curiosity)

      Comment


      • #53
        Originally posted by 144Hz View Post
        halo9en They are working on that as well. Or working around since the problems are kernel related.
        https://gitlab.gnome.org/GNOME/mutte...e_requests/923
        And those workarounds would be gtk specific (mutter), while as you said the problems are kernel related.

        Comment


        • #54
          Originally posted by rastersoft View Post

          Four???? Can you point me to them? (just curiosity)
          1. https://github.com/rfjakob/earlyoom earlyoom
          2. https://github.com/hakavlad/nohang nohang
          3. https://github.com/facebookincubator/oomd oomd
          4. https://gitlab.freedesktop.org/hades...emory-monitor/ low-memory-monitor

          Comment


          • #55
            Originally posted by 144Hz View Post
            halo9en They are working on that as well. Or working around since the problems are kernel related.
            https://gitlab.gnome.org/GNOME/mutte...e_requests/923
            How would this help compared to the current realtime flag?

            Comment


            • #56
              Originally posted by blacknova View Post
              Linux has nasty problem of paging everything out on disk IO. My dev system has 32GiB RAM, copying somewhat around 100GiB from one HDD to another via NTFS-3g after half a hour made system barely usable, it still had considirable amount of free and usable mem (around 16GB), but desktop processes have been paged out.
              You can try what I mentioned in post #13 of this thread and see if it helps.
              I am pretty sure it will fix your problem.

              Comment


              • #57
                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.
                Take a look at this presentation form All Systems Go! 2019: https://www.youtube.com/watch?v=S0WqoD2_tVs

                Comment


                • #58
                  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.
                  Isn't this already possible. Mount a ramfs, copy /bin directories, mount over existing /bin ?

                  Comment


                  • #59
                    Mmmm... when you said there were at least four, I presumed that you talked about low memory monitors, but only the fourth is that; the other three are OOM Killers, which should be just a "last resource" option. Before doing that, all and every application in the system should have the opportunity of freeing some non-critical memory, and for that, only the fourth one is useful...

                    Comment


                    • #60
                      The whole idea of OOM is wrong. The user doesn't want his process killed. When building a distribution with Yocto I want it built, even if it tries to build gcc and nodejs each with 8 threads simultaneously on a quad core + HT cpu.

                      What actually needs to be done is restrict the number of swapin. This can in theory be implemented in the scheduler.

                      That this will work can easily be verified by stopping (SIGSTOP) the offending process. It will get swapped out by the remaining processes, but not swapped in again and everything will return to normal. SIGCONT will continue it again.

                      Of course the process needs to be allowed to run longer then the swapin time needed.

                      Comment

                      Working...
                      X