Hastening process cleanup with process_mrelease()

Posted Jul 26, 2021 20:26 UTC (Mon) by josh (subscriber, #17465)
Parent article: Hastening process cleanup with process_mrelease()

> 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. In that case, though, the work would be done in the context of the process sending the signal, which might not be welcome.

This doesn't seem like it needs a completely separate syscall. pidfd_send_signal takes flags, and a "reap process memory immediately" flag seems like it would fit well there.

Hastening process cleanup with process_mrelease()

Posted Jul 26, 2021 23:19 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (1 responses)

If you want process A to do the killing, and process B to do the reaping, then you need a new syscall regardless.

(Why have two? To improve throughput. A can spend all its CPU cycles on identifying useful things to kill, and B can spend its CPU cycles on actual reaping. You can then adjust the relative priorities of those two tasks independently of each other with the usual process-management techniques.)

Hastening process cleanup with process_mrelease()

Posted Jul 27, 2021 1:10 UTC (Tue) by josh (subscriber, #17465) [Link]

Interesting point! Technically process B (or thread B) could do the kill as well after A picked out a target, but it does make sense to have a high-priority process do the kill and a lower-priority (but still higher-priority-than-normal) process do the reclamation.

Hastening process cleanup with process_mrelease()

Posted Jul 30, 2021 14:03 UTC (Fri) by brauner (subscriber, #109349) [Link]

> This doesn't seem like it needs a completely separate syscall. pidfd_send_signal takes flags, and a "reap process memory immediately" flag seems like it would fit well there.

In one of the first iterations this has been a flag to pidfd_send_signal() but I really disliked it. I get why it feels appealing but how memory is released has nothing to do with signaling imho. It's better suited as a separate API where it can also be extended in the future.