Hastening Linux process cleanup with process_mrelease

# · ✸ 92 · 💬 35 · one month ago · lwn.net · chmaynard
Such systems often run process managers that will kill off the low-priority processes in these situations; perhaps the most widespread example of this pattern is Android, which will kill background apps if the available memory is insufficient for whatever is running in the foreground. If the killed process finds itself blocked in an uninterruptible sleep, that cleanup work could be delayed indefinitely. Delays in process cleanup can have immediate and visible effects on the higher-priority workloads; these can include jerky response on a handset or a delay in the delivery of a cat video to an impatient viewer. Back in 2015, the development of the OOM reaper addressed this problem by taking the memory cleanup work out of the dying process's hands and making it the responsibility of a separate kernel thread. That made OOM killing significantly more robust, with the ability to free memory quickly even if the chosen process is not able to exit immediately. The pidfd argument is a pidfd identifying the process of interest; that process must be exiting operation) when the call is made. The task of going through the process's address space and freeing up all that memory will be done by the process that calls process mrelease(), which may or may not be the process that killed the target in the first place. The kernel can then do this work with the priority of the calling process, and with its CPU assignments, allowing the cleanup work to be contained where it will not interfere with the system workload. An alternative that was discussed with an earlier attempt to solve this problem was to just unconditionally reap the memory of a process when it is killed, without requiring a separate system call to make that happen.
Hastening Linux process cleanup with process_mrelease



Archive | Send Feedback | WebAssembly Version (beta)