archive mirror
 help / color / mirror / Atom feed
From: Suren Baghdasaryan <>
Subject: [PATCH v3 1/2] mm: introduce process_mrelease system call
Date: Thu, 22 Jul 2021 18:14:35 -0700	[thread overview]
Message-ID: <> (raw)

In modern systems it's not unusual to have a system component monitoring
memory conditions of the system and tasked with keeping system memory
pressure under control. One way to accomplish that is to kill
non-essential processes to free up memory for more important ones.
Examples of this are Facebook's OOM killer daemon called oomd and
Android's low memory killer daemon called lmkd.
For such system component it's important to be able to free memory
quickly and efficiently. Unfortunately the time process takes to free
up its memory after receiving a SIGKILL might vary based on the state
of the process (uninterruptible sleep), size and OPP level of the core
the process is running. A mechanism to free resources of the target
process in a more predictable way would improve system's ability to
control its memory pressure.
Introduce process_mrelease system call that releases memory of a dying
process from the context of the caller. This way the memory is freed in
a more controllable way with CPU affinity and priority of the caller.
The workload of freeing the memory will also be charged to the caller.
The operation is allowed only on a dying process.

Previously I proposed a number of alternatives to accomplish this:
- extending
pidfd_send_signal to allow memory reaping using oom_reaper thread;
- extending
pidfd_send_signal to reap memory of the target process synchronously from
the context of the caller;
support for process_madvise implementing synchronous memory reaping.

The end of the last discussion culminated with suggestion to introduce a
dedicated system call (
The reasoning was that the new variant of process_madvise
  a) does not work on an address range
  b) is destructive
  c) doesn't share much code at all with the rest of process_madvise
From the userspace point of view it was awkward and inconvenient to provide
memory range for this operation that operates on the entire address space.
Using special flags or address values to specify the entire address space
was too hacky.

The API is as follows,

          int process_mrelease(int pidfd, unsigned int flags);

          The process_mrelease() system call is used to free the memory of
          a process which was sent a SIGKILL signal.

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

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

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

          EBADF  pidfd is not a valid PID file descriptor.

          EAGAIN Failed to release part of the address space.

          EINVAL flags is not 0.

          EINVAL The task does not have a pending SIGKILL or its memory is
                 shared with another process with no pending SIGKILL.

          ENOSYS This system call is not supported by kernels built with no
                 MMU support (CONFIG_MMU=n).

          ESRCH  The target process does not exist (i.e., it has terminated
                 and been waited on).

Signed-off-by: Suren Baghdasaryan <>
changes in v3:
- Added #ifdef CONFIG_MMU inside process_mrelease to keep task_will_free_mem in
the same place, per David Hildenbrand
- Reordered variable definitions in process_mrelease, per David Hildenbrand

 mm/oom_kill.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index c729a4c4a1ac..8bf7a1020ac5 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -28,6 +28,7 @@
 #include <linux/sched/task.h>
 #include <linux/sched/debug.h>
 #include <linux/swap.h>
+#include <linux/syscalls.h>
 #include <linux/timex.h>
 #include <linux/jiffies.h>
 #include <linux/cpuset.h>
@@ -1141,3 +1142,56 @@ void pagefault_out_of_memory(void)
+SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags)
+#ifdef CONFIG_MMU
+	struct mm_struct *mm = NULL;
+	struct task_struct *task;
+	unsigned int f_flags;
+	struct pid *pid;
+	long ret = 0;
+	if (flags != 0)
+		return -EINVAL;
+	pid = pidfd_get_pid(pidfd, &f_flags);
+	if (IS_ERR(pid))
+		return PTR_ERR(pid);
+	task = get_pid_task(pid, PIDTYPE_PID);
+	if (!task) {
+		ret = -ESRCH;
+		goto put_pid;
+	}
+	/*
+	 * If the task is dying and in the process of releasing its memory
+	 * then get its mm.
+	 */
+	task_lock(task);
+	if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
+		mm = task->mm;
+		mmget(mm);
+	}
+	task_unlock(task);
+	if (!mm) {
+		ret = -EINVAL;
+		goto put_task;
+	}
+	mmap_read_lock(mm);
+	if (!__oom_reap_task_mm(mm))
+		ret = -EAGAIN;
+	mmap_read_unlock(mm);
+	mmput(mm);
+	put_task_struct(task);
+	put_pid(pid);
+	return ret;
+	return -ENOSYS;
+#endif /* CONFIG_MMU */

             reply	other threads:[~2021-07-23  1:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23  1:14 Suren Baghdasaryan [this message]
2021-07-23  1:14 ` [PATCH v3 2/2] mm: wire up syscall process_mrelease Suren Baghdasaryan
2021-07-23  2:03 ` [PATCH v3 1/2] mm: introduce process_mrelease system call Shakeel Butt
     [not found]   ` <>
2021-07-23  6:20     ` Michal Hocko
     [not found]       ` <>
2021-07-23  8:15         ` David Hildenbrand
2021-07-23  8:18           ` Suren Baghdasaryan
2021-07-23  8:53         ` Michal Hocko
2021-07-23 13:46           ` Shakeel Butt
2021-07-23 16:08             ` Suren Baghdasaryan
2021-07-23 17:00               ` Shakeel Butt
2021-07-26  7:27                 ` Michal Hocko
2021-07-26 13:43                   ` Shakeel Butt
2021-08-02 19:53                     ` Suren Baghdasaryan
2021-08-02 20:05                       ` Shakeel Butt
2021-08-02 20:08                         ` Suren Baghdasaryan
2021-08-02 22:16                           ` Suren Baghdasaryan
2021-07-23 13:40       ` Shakeel Butt
2021-07-26  8:20   ` Michal Hocko

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).