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.
The proposed process_reap system call is designed to reclaim memory of a dying process from the context of the caller. Using process_reap should allow the memory to be freed faster with the CPU affinity and priority of the caller. Process_reap can only be used on processes that are dying via SIGKILL such as when triggered via out-of-memory / memory pressure daemons.
The proposal sent out by Google's Suren Baghdasaryan explains, "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."
Since being published in late June some have questioned whether process_reap really needs its own system call and other questions, but so far does appear to be an idea not outright criticized or shot down and could end up working its way to mainline in a future Linux kernel release.
The proposed process_reap system call is designed to reclaim memory of a dying process from the context of the caller. Using process_reap should allow the memory to be freed faster with the CPU affinity and priority of the caller. Process_reap can only be used on processes that are dying via SIGKILL such as when triggered via out-of-memory / memory pressure daemons.
The proposal sent out by Google's Suren Baghdasaryan explains, "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."
Since being published in late June some have questioned whether process_reap really needs its own system call and other questions, but so far does appear to be an idea not outright criticized or shot down and could end up working its way to mainline in a future Linux kernel release.
7 Comments