Re: [PATCH 1/1] mm: introduce process_reap system call

* Suren Baghdasaryan:

On Wed, Jul 7, 2021 at 10:41 PM Florian Weimer [off-list ref] wrote:

quoted

* Suren Baghdasaryan:

quoted

On Wed, Jul 7, 2021 at 2:47 AM Florian Weimer [off-list ref] wrote:

quoted

* Suren Baghdasaryan:

quoted

The API is as follows,

          int process_reap(int pidfd, unsigned int flags);

        DESCRIPTION
          The process_reap() system call is used to free the memory of a
          dying process.

          The pidfd selects the process referred to by the PID file
          descriptor.
          (See pidofd_open(2) for further information)

          The flags argument is reserved for future use; currently, this
          argument must be specified as 0.

        RETURN VALUE
          On success, process_reap() returns 0. On error, -1 is returned
          and errno is set to indicate the error.

I think the manual page should mention what it means for a process to be
“dying”, and how to move a process to this state.

Thanks for the suggestion, Florian! Would replacing "dying process"
with "process which was sent a SIGKILL signal" be sufficient?

That explains very clearly the requirement, but it raises the question
why this isn't an si_code flag for rt_sigqueueinfo, reusing the existing
system call.

I think you are suggesting to use sigqueue() to deliver the signal and
perform the reaping when a special value accompanies it. This would be
somewhat similar to my early suggestion to use a flag in

7 more quoted lines

Does this mean that you need two threads, one that sends SIGKILL, and
one that calls process_reap?  Given that sending SIGKILL is blocking
with the existing interfaces?

Please also note that asynchronous deallocation of resources leads to
bugs and can cause unrelated workloads to fail.  For example, in some
configurations, clone can fail with EAGAIN even in cases where the total
number of tasks is clearly bounded because the kernel signals task exit
to applications before all resources are deallocated.  I'm worried that
the new interface makes things quite a bit worse in this regard.

Thanks,
Florian

On Wed, Jul 7, 2021 at 11:15 PM Florian Weimer [off-list ref] wrote:

* Suren Baghdasaryan:

quoted

On Wed, Jul 7, 2021 at 10:41 PM Florian Weimer [off-list ref] wrote:

quoted

* Suren Baghdasaryan:

quoted

On Wed, Jul 7, 2021 at 2:47 AM Florian Weimer [off-list ref] wrote:

quoted

* Suren Baghdasaryan:

quoted

The API is as follows,

          int process_reap(int pidfd, unsigned int flags);

        DESCRIPTION
          The process_reap() system call is used to free the memory of a
          dying process.

          The pidfd selects the process referred to by the PID file
          descriptor.
          (See pidofd_open(2) for further information)

          The flags argument is reserved for future use; currently, this
          argument must be specified as 0.

        RETURN VALUE
          On success, process_reap() returns 0. On error, -1 is returned
          and errno is set to indicate the error.

I think the manual page should mention what it means for a process to be
“dying”, and how to move a process to this state.

Thanks for the suggestion, Florian! Would replacing "dying process"
with "process which was sent a SIGKILL signal" be sufficient?

That explains very clearly the requirement, but it raises the question
why this isn't an si_code flag for rt_sigqueueinfo, reusing the existing
system call.

14 more quoted lines

Sending SIGKILL is blocking in terms of delivering the signal, but it
does not block waiting for SIGKILL to be processed by the signal
recipient and memory to be released. When I was talking about
"blocking", I meant that current kill() and friends do not block to
wait for SIGKILL to be processed.
process_reap() will block until the memory is released. Whether the
userspace caller is using it right after sending a SIGKILL to reclaim
the memory synchronously or spawns a separate thread to reclaim memory
asynchronously is up to the user. Both patterns are supported.

Please also note that asynchronous deallocation of resources leads to
bugs and can cause unrelated workloads to fail.  For example, in some
configurations, clone can fail with EAGAIN even in cases where the total
number of tasks is clearly bounded because the kernel signals task exit
to applications before all resources are deallocated.  I'm worried that
the new interface makes things quite a bit worse in this regard.

The process_reap() releases memory synchronously, no kthreads are
being used. If asynchronous release is required, the userspace would
need to spawn a userspace thread and issue this syscall from it. I
hope this clears your concerns, which I think are about asynchronous
deallocations within the kernel.
Thanks!

Thanks,
Florian