Re: [PATCH 1/1] RFC: add pidfd_send_signal flag to reclaim mm while killing a process

On Wed, Nov 18, 2020 at 11:51 AM Suren Baghdasaryan [off-list ref] wrote:

On Wed, Nov 18, 2020 at 11:32 AM Michal Hocko [off-list ref] wrote:

quoted

On Wed 18-11-20 11:22:21, Suren Baghdasaryan wrote:

quoted

On Wed, Nov 18, 2020 at 11:10 AM Michal Hocko [off-list ref] wrote:

quoted

On Fri 13-11-20 18:16:32, Andrew Morton wrote:
[...]

quoted

It's all sounding a bit painful (but not *too* painful).  But to
reiterate, I do think that adding the ability for a process to shoot
down a large amount of another process's memory is a lot more generally
useful than tying it to SIGKILL, agree?

I am not sure TBH. Is there any reasonable usecase where uncoordinated
memory tear down is OK and a target process which is able to see the
unmapped memory?

I think uncoordinated memory tear down is a special case which makes
sense only when the target process is being killed (and we can enforce
that by allowing MADV_DONTNEED to be used only if the target process
has pending SIGKILL).

That would be safe but then I am wondering whether it makes sense to
implement as a madvise call. It is quite strange to expect somebody call
a syscall on a killed process. But this is more a detail. I am not a
great fan of a more generic MADV_DONTNEED on a remote process. This is
just too dangerous IMHO.

Agree 100%

I assumed here that by "a more generic MADV_DONTNEED on a remote
process" you meant "process_madvise(MADV_DONTNEED) applied to a
process that is not being killed". Re-reading your comment I realized
that you might have meant "process_madvice() with generic support to
large memory areas". I hope I understood you correctly.

quoted

quoted

However, the ability to apply other flavors of
process_madvise() to large memory areas spanning multiple VMAs can be
useful in more cases.

Yes I do agree with that. The error reporting would be more tricky but
I am not really sure that the exact reporting is really necessary for
advice like interface.

Andrew's suggestion for this special mode to change return semantics
to the usual "0 or error code" seems to me like the most reasonable
way to deal with the return value limitation.

quoted

quoted

For example in Android we will use
process_madvise(MADV_PAGEOUT) to "shrink" an inactive background
process.

That makes sense to me.
--
Michal Hocko
SUSE Labs