On Wed, Jun 30, 2021 at 11:51 AM Suren Baghdasaryan [off-list ref] wrote:

On Wed, Jun 30, 2021 at 11:26 AM Andy Lutomirski [off-list ref] wrote:

quoted

On Wed, Jun 23, 2021 at 12:28 PM Suren Baghdasaryan [off-list ref] wrote:

quoted

In modern systems it's not unusual to have a system component monitoring
memory conditions of the system and tasked with keeping system memory
pressure under control. One way to accomplish that is to kill
non-essential processes to free up memory for more important ones.
Examples of this are Facebook's OOM killer daemon called oomd and
Android's low memory killer daemon called lmkd.
For such system component it's important to be able to free memory
quickly and efficiently. Unfortunately the time process takes to free
up its memory after receiving a SIGKILL might vary based on the state
of the process (uninterruptible sleep), size and OPP level of the core
the process is running. A mechanism to free resources of the target
process in a more predictable way would improve system's ability to
control its memory pressure.
Introduce process_reap system call that reclaims memory of a dying process
from the context of the caller. This way the memory in freed in a more
controllable way with CPU affinity and priority of the caller. The workload
of freeing the memory will also be charged to the caller.
The operation is allowed only on a dying process.

At the risk of asking a potentially silly question, should this just
be a file in procfs?

Hmm. I guess it's doable if procfs will not disappear too soon before
memory is released... syscall also supports parameters, in this case
flags can be used in the future to support PIDs in addition to PIDFDs
for example.
Before looking more in that direction, a silly question from my side:
why procfs interface would be preferable to a syscall?

It avoids using a syscall nr.  (Admittedly a syscall nr is not *that*
precious of a resource.)  It also makes it possible to use a shell
script to do this, which is maybe useful.

--Andy