Re: [PATCH 1/1] mm: introduce process_reap system call
From: Christian Brauner <hidden>
Date: 2021-07-02 15:27:35
Also in:
linux-mm, lkml
On Thu, Jul 01, 2021 at 03:59:48PM -0700, Suren Baghdasaryan wrote:
On Wed, Jun 30, 2021 at 5:44 PM Andy Lutomirski [off-list ref] wrote:quoted
On Wed, Jun 30, 2021 at 2:45 PM Johannes Weiner [off-list ref] wrote:quoted
On Wed, Jun 30, 2021 at 11:51:36AM -0700, Suren Baghdasaryan wrote:quoted
On Wed, Jun 30, 2021 at 11:26 AM Andy Lutomirski [off-list ref] wrote:quoted
Also, please consider removing all mention of the word "reap" from the user API. For better or for worse, "reap" in UNIX refers to what happens when a dead task gets wait()ed. I sincerely wish I could go back in time and gently encourage whomever invented that particular abomination to change their mind, but my time machine doesn't work.I see. Thanks for the note. How about process_mem_release() and replacing reap with release everywhere?I don't quite understand the objection. This syscall works on tasks that are at the end of their life, right? Isn't something like process_mreap() establishing exactly the mental link we want here? Release is less descriptive for what this thing is to be used for.For better or for worse, "reap" means to make a zombie pid go away. From the description, this new operation takes a dying process (not necessarily a zombie yet) and aggressively frees its memory. This is a different optioneration. How about "free_dying_process_memory"?process_mreap sounds definitely better and in line with names like process_madvise. So maybe we can use it?
That one was my favorite from the list I gave too but maybe we can satisfy Andy too if we use one of: - process_mfree() - process_mrelease()