From: Suren Baghdasaryan <surenb@google.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>,
linux-api@vger.kernel.org, linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Rientjes <rientjes@google.com>,
Matthew Wilcox <willy@infradead.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <guro@fb.com>, Rik van Riel <riel@surriel.com>,
Christian Brauner <christian@brauner.io>,
Oleg Nesterov <oleg@redhat.com>,
Tim Murray <timmurray@google.com>,
kernel-team <kernel-team@android.com>,
LKML <linux-kernel@vger.kernel.org>,
Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [RFC]: userspace memory reaping
Date: Thu, 15 Oct 2020 12:32:22 -0700 [thread overview]
Message-ID: <CAJuCfpF1MxHbUQ-eSGO5nPDVeGrFGUDrdvQgh7iVNX46-=0i4w@mail.gmail.com> (raw)
In-Reply-To: <20201015184349.GA3930989@google.com>
On Thu, Oct 15, 2020 at 11:43 AM Minchan Kim <minchan@kernel.org> wrote:
>
> On Thu, Oct 15, 2020 at 11:20:30AM +0200, Michal Hocko wrote:
>
> > > > I do have a vague recollection that we have discussed a kill(2) based
> > > > approach as well in the past. Essentially SIG_KILL_SYNC which would
> > > > not only send the signal but it would start a teardown of resources
> > > > owned by the task - at least those we can remove safely. The interface
> > > > would be much more simple and less tricky to use. You just make your
> > > > userspace oom killer or potentially other users call SIG_KILL_SYNC which
> > > > will be more expensive but you would at least know that as many
> > > > resources have been freed as the kernel can afford at the moment.
> > >
> > > Correct, my early RFC here
> > > https://patchwork.kernel.org/project/linux-mm/patch/20190411014353.113252-3-surenb@google.com
> > > was using a new flag for pidfd_send_signal() to request mm reaping by
> > > oom-reaper kthread. IIUC you propose to have a new SIG_KILL_SYNC
> > > signal instead of a new pidfd_send_signal() flag and otherwise a very
> > > similar solution. Is my understanding correct?
> >
> > Well, I think you shouldn't focus too much on the oom-reaper aspect
> > of it. Sure it can be used for that but I believe that a new signal
> > should provide a sync behavior. People more familiar with the process
> > management would be better off defining what is possible for a new sync
> > signal. Ideally not only pro-active process destruction but also sync
> > waiting until the target process is released so that you know that once
> > kill syscall returns the process is gone.
>
> If we approach with signal, I am not sure we need to create new signal
> rather than pidfd and fsync(2) semantic.
>
> Furthermore, process_madvise makes the work in the caller context but
> signal might work somewhere else context depending on implemenation(
> oom reaper or CPU resumed the task). I am not sure it it fulfils Suren's
> requirement.
>
> One more thing to think over: Even though we spent some overhead to
> read /proc/pid/maps, we could make zapping in parallel in userspace
> with multi thread approach. I am not sure what's the win since Suren
> also care about zapping performance.
Sorry Minchan, I did not see your reply while replying to Michal...
Even if we do the reading/reaping in parallel, we still have to issue
10s of read() syscalls to consume the entire /proc/pid/maps file. Plus
I'm not sure how much mmap_sem contention such parallel operation
(reaping taking write lock and maps reading taking read lock) would
generate. If we go this route I think a syscall to read a vector of
VMAs would be way more performant and userspace usage would be much
simpler.
next prev parent reply other threads:[~2020-10-15 19:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-15 0:43 [RFC]: userspace memory reaping Suren Baghdasaryan
2020-09-15 0:45 ` Suren Baghdasaryan
2020-10-14 12:09 ` Michal Hocko
2020-10-14 16:57 ` Suren Baghdasaryan
2020-10-14 18:39 ` minchan
2020-10-15 9:20 ` Michal Hocko
2020-10-15 18:43 ` Minchan Kim
2020-10-15 19:32 ` Suren Baghdasaryan [this message]
2020-10-15 19:25 ` Suren Baghdasaryan
2020-11-02 20:29 ` Suren Baghdasaryan
2020-11-03 9:35 ` Michal Hocko
2020-11-03 21:28 ` Suren Baghdasaryan
2020-11-03 21:32 ` Minchan Kim
2020-11-03 21:40 ` Suren Baghdasaryan
2020-11-03 21:46 ` Minchan Kim
2020-11-04 6:58 ` Michal Hocko
2020-11-04 20:40 ` Minchan Kim
2020-11-05 12:20 ` Michal Hocko
2020-11-05 16:50 ` Suren Baghdasaryan
2020-11-05 17:07 ` Minchan Kim
2020-11-05 17:16 ` Michal Hocko
2020-11-05 17:21 ` Suren Baghdasaryan
2020-11-05 17:41 ` Minchan Kim
2020-11-05 17:43 ` Michal Hocko
2020-11-05 18:02 ` Suren Baghdasaryan
2020-11-13 17:37 ` Suren Baghdasaryan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJuCfpF1MxHbUQ-eSGO5nPDVeGrFGUDrdvQgh7iVNX46-=0i4w@mail.gmail.com' \
--to=surenb@google.com \
--cc=akpm@linux-foundation.org \
--cc=christian@brauner.io \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@android.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=oleg@redhat.com \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=timmurray@google.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).