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

[phoronix]

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?page=news_item&px=Linux-process_reap-syscall

[programmerjake]

phoronix you should probably add a link to the actual proposal:

https://lore.kernel.org/lkml/[email protected]/

[tildearrow]

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.

[Michael]

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

Yep should be fixed now. Thanks.

[andreano]

uninterruptible sleep

So you can reap the memory of an unkillable process, but still not kill it?

[andreano]

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.

[tildearrow]

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....

[yurikoles]

Sorry, I can't resist.