linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Suren Baghdasaryan <surenb@google.com>
To: surenb@google.com
Cc: akpm@linux-foundation.org, mhocko@kernel.org, mhocko@suse.com,
	 rientjes@google.com, willy@infradead.org, hannes@cmpxchg.org,
	guro@fb.com,  riel@surriel.com, minchan@kernel.org,
	christian@brauner.io, oleg@redhat.com,  timmurray@google.com,
	linux-api@vger.kernel.org, linux-mm@kvack.org,
	 linux-kernel@vger.kernel.org, kernel-team@android.com
Subject: [PATCH 0/2] userspace memory reaping using process_madvise
Date: Mon, 23 Nov 2020 21:39:41 -0800	[thread overview]
Message-ID: <20201124053943.1684874-1-surenb@google.com> (raw)

When a process is being killed it might be in an uninterruptible sleep
which leads to an unpredictable delay in its memory reclaim. In low memory
situations, when it's important to free up memory quickly, such delay is
problematic. Kernel solves this problem with oom-reaper thread which
performs memory reclaim even when the victim process is not runnable.
Userspace currently lacks such mechanisms and the need and potential
solutions were discussed before (see links below).
This patchset provides a mechanism to perform memory reclaim of an
external process using process_madvise(MADV_DONTNEED). The chosen
mechanism is the result of the latest discussion at [4].
The first patch adds PMADV_FLAG_RANGE flag for process_madvise to operate
on large address ranges spanning multiple VMAs. Currently it supports only
the entire memory of a process. This is done to keep things simple and
since it's the only real usecase we currently know of. In the future this
can be developed further to support other large ranges. One way to do that
is suggested in [5].
The second patch enables MADV_DONTNEED behavior for process_madvise to
perform memory reclaim of an external process.

1. https://patchwork.kernel.org/cover/10894999
2. https://lwn.net/Articles/787217
3. https://lore.kernel.org/linux-api/CAJuCfpGz1kPM3G1gZH+09Z7aoWKg05QSAMMisJ7H5MdmRrRhNQ@mail.gmail.com
4. https://lkml.org/lkml/2020/11/13/849
5. https://lkml.org/lkml/2020/11/18/1076

Suren Baghdasaryan (2):
  mm/madvise: allow process_madvise operations on entire memory range
  mm/madvise: add process_madvise MADV_DONTNEER support

 arch/alpha/include/uapi/asm/mman.h           |  4 +
 arch/mips/include/uapi/asm/mman.h            |  4 +
 arch/parisc/include/uapi/asm/mman.h          |  4 +
 arch/xtensa/include/uapi/asm/mman.h          |  4 +
 fs/io_uring.c                                |  2 +-
 include/linux/mm.h                           |  3 +-
 include/uapi/asm-generic/mman-common.h       |  4 +
 mm/madvise.c                                 | 81 ++++++++++++++++++--
 tools/include/uapi/asm-generic/mman-common.h |  4 +
 9 files changed, 101 insertions(+), 9 deletions(-)

-- 
2.29.2.454.gaff20da3a2-goog



             reply	other threads:[~2020-11-24  5:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24  5:39 Suren Baghdasaryan [this message]
2020-11-24  5:39 ` [PATCH 1/2] mm/madvise: allow process_madvise operations on entire memory range Suren Baghdasaryan
2020-11-25 23:13   ` Minchan Kim
2020-11-25 23:23     ` Suren Baghdasaryan
2020-11-25 23:43       ` Minchan Kim
2020-11-30 19:01         ` Suren Baghdasaryan
2020-12-08  7:23           ` Suren Baghdasaryan
2020-12-11 20:27     ` Jann Horn
2020-12-11 23:01       ` Minchan Kim
2020-12-12  0:16         ` Jann Horn
2020-12-22 13:44       ` Christoph Hellwig
2020-12-22 17:48         ` Suren Baghdasaryan
2020-12-23  4:09           ` Suren Baghdasaryan
2020-12-23  7:57           ` Christoph Hellwig
2020-12-23 17:32             ` Suren Baghdasaryan
2020-11-24  5:39 ` [PATCH 2/2] mm/madvise: add process_madvise MADV_DONTNEER support Suren Baghdasaryan
2020-11-24 13:42   ` Oleg Nesterov
2020-11-24 16:42     ` Suren Baghdasaryan
2020-12-08 23:40   ` Jann Horn
2020-12-08 23:59     ` 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=20201124053943.1684874-1-surenb@google.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=mhocko@kernel.org \
    --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).