Announcement

Collapse
No announcement yet.

Process_Reap Syscall Proposed For Linux To More Quickly Reclaim Memory Under Pressure

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

  • Process_Reap Syscall Proposed For Linux To More Quickly Reclaim Memory Under Pressure

    Phoronix: Process_Reap Syscall Proposed For Linux To More Quickly Reclaim Memory Under Pressure

    While there are the likes of OOMD / systemd-oomd gaining acceptance as a daemon for Linux systems to deal with killing off processes and other behavior under system memory (RAM) pressure, there still is an issue of the time it takes until the memory is reclaimed by those dying processes. Google engineers at the end of June proposed "process_reap" as a new system call to help in that memory recovery...

    https://www.phoronix.com/scan.php?pa...s_reap-syscall

  • #2
    phoronix you should probably add a link to the actual proposal:
    https://lore.kernel.org/lkml/[email protected]/

    Comment


    • #3
      What about just not page out executable code?
      That way you considerably reduce freezing in low memory situations by not having to read executable code from the disk over and over and over.

      Comment


      • #4
        Originally posted by programmerjake View Post
        phoronix you should probably add a link to the actual proposal:
        https://lore.kernel.org/lkml/[email protected]/
        Yep should be fixed now. Thanks.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #5
          Originally posted by article
          uninterruptible sleep
          So you can reap the memory of an unkillable process, but still not kill it?

          Comment


          • #6
            Originally posted by tildearrow View Post
            What about just not page out executable code?
            Do you mean anonymous pages (pretty much disable swap)? If you look at /proc/self/maps, executable code is always mapped readonly. If my understanding is right, such file-backed readonly "clean pages" are just dropped from memory, not paged out.

            If you mean disable swap, I think that has been tried, and has its own problems. Sometimes, the OOM killer just takes an infinite time to kick in, and disabling swap did not solve that for me last I tried. It also reduces the time to react (as in not even earlyoom can react sometimes) before the machine locks up.

            If you mean lock the pages in ram, that's possible (mlockall), and I suppose would be a very reasonable thing for an OOM daemon to do.
            Last edited by andreano; 12 July 2021, 10:04 AM.

            Comment


            • #7
              Originally posted by andreano View Post

              Do you mean anonymous pages (pretty much disable swap)? If you look at /proc/self/maps, executable code is always mapped readonly. If my understanding is right, such file-backed readonly "clean pages" are just dropped from memory, not paged out.

              If you mean disable swap, I think that has been tried, and has its own problems. Sometimes, the OOM killer just takes an infinite time to kick in, and disabling swap did not solve that for me last I tried. It also reduces the time to react (as in not even earlyoom can react sometimes) before the machine locks up.

              If you mean lock the pages in ram, that's possible (mlockall), and I suppose would be a very reasonable thing for an OOM daemon to do.
              I meant "dropping from memory", so the latter.

              However, I feel like that should be done by the kernel....

              Comment


              • #8

                Sorry, I can't resist.​​​​​​​

                Comment

                Working...
                X