* [PATCH v3 1/2] mm: introduce process_mrelease system call @ 2021-07-23 1:14 Suren Baghdasaryan 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 0 siblings, 2 replies; 18+ messages in thread From: Suren Baghdasaryan @ 2021-07-23 1:14 UTC (permalink / raw) To: akpm Cc: mhocko, mhocko, rientjes, willy, hannes, guro, riel, minchan, christian, hch, oleg, david, jannh, shakeelb, luto, christian.brauner, fweimer, jengelh, timmurray, linux-api, linux-mm, linux-kernel, kernel-team, surenb 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: - https://lore.kernel.org/patchwork/patch/1060407 extending pidfd_send_signal to allow memory reaping using oom_reaper thread; - https://lore.kernel.org/patchwork/patch/1338196 extending pidfd_send_signal to reap memory of the target process synchronously from the context of the caller; - https://lore.kernel.org/patchwork/patch/1344419/ to add MADV_DONTNEED support for process_madvise implementing synchronous memory reaping. The end of the last discussion culminated with suggestion to introduce a dedicated system call (https://lore.kernel.org/patchwork/patch/1344418/#1553875) 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); DESCRIPTION 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 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_mrelease() returns 0. On error, -1 is returned and errno is set to indicate the error. ERRORS 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 <surenb@google.com> --- 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) out_of_memory(&oc); mutex_unlock(&oom_lock); } + +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: + put_task_struct(task); +put_pid: + put_pid(pid); + return ret; +#else + return -ENOSYS; +#endif /* CONFIG_MMU */ +} -- 2.32.0.432.gabb21c7263-goog ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH v3 2/2] mm: wire up syscall process_mrelease 2021-07-23 1:14 [PATCH v3 1/2] mm: introduce process_mrelease system call Suren Baghdasaryan @ 2021-07-23 1:14 ` Suren Baghdasaryan 2021-07-23 2:03 ` [PATCH v3 1/2] mm: introduce process_mrelease system call Shakeel Butt 1 sibling, 0 replies; 18+ messages in thread From: Suren Baghdasaryan @ 2021-07-23 1:14 UTC (permalink / raw) To: akpm Cc: mhocko, mhocko, rientjes, willy, hannes, guro, riel, minchan, christian, hch, oleg, david, jannh, shakeelb, luto, christian.brauner, fweimer, jengelh, timmurray, linux-api, linux-mm, linux-kernel, kernel-team, surenb Split off from prev patch in the series that implements the syscall. Signed-off-by: Suren Baghdasaryan <surenb@google.com> --- arch/alpha/kernel/syscalls/syscall.tbl | 2 ++ arch/arm/tools/syscall.tbl | 2 ++ arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 2 ++ arch/ia64/kernel/syscalls/syscall.tbl | 2 ++ arch/m68k/kernel/syscalls/syscall.tbl | 2 ++ arch/microblaze/kernel/syscalls/syscall.tbl | 2 ++ arch/mips/kernel/syscalls/syscall_n32.tbl | 2 ++ arch/mips/kernel/syscalls/syscall_n64.tbl | 2 ++ arch/mips/kernel/syscalls/syscall_o32.tbl | 2 ++ arch/parisc/kernel/syscalls/syscall.tbl | 2 ++ arch/powerpc/kernel/syscalls/syscall.tbl | 2 ++ arch/s390/kernel/syscalls/syscall.tbl | 2 ++ arch/sh/kernel/syscalls/syscall.tbl | 2 ++ arch/sparc/kernel/syscalls/syscall.tbl | 2 ++ arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + arch/xtensa/kernel/syscalls/syscall.tbl | 2 ++ include/linux/syscalls.h | 1 + include/uapi/asm-generic/unistd.h | 4 +++- kernel/sys_ni.c | 1 + 21 files changed, 38 insertions(+), 2 deletions(-) diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl index a17687ed4b51..605645eae04c 100644 --- a/arch/alpha/kernel/syscalls/syscall.tbl +++ b/arch/alpha/kernel/syscalls/syscall.tbl @@ -486,3 +486,5 @@ 554 common landlock_create_ruleset sys_landlock_create_ruleset 555 common landlock_add_rule sys_landlock_add_rule 556 common landlock_restrict_self sys_landlock_restrict_self +# 557 reserved for memfd_secret +558 common process_mrelease sys_process_mrelease diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl index c5df1179fc5d..2f32eb8beca8 100644 --- a/arch/arm/tools/syscall.tbl +++ b/arch/arm/tools/syscall.tbl @@ -460,3 +460,5 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 common process_mrelease sys_process_mrelease diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h index 727bfc3be99b..3cb206aea3db 100644 --- a/arch/arm64/include/asm/unistd.h +++ b/arch/arm64/include/asm/unistd.h @@ -38,7 +38,7 @@ #define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE + 5) #define __ARM_NR_COMPAT_END (__ARM_NR_COMPAT_BASE + 0x800) -#define __NR_compat_syscalls 447 +#define __NR_compat_syscalls 449 #endif #define __ARCH_WANT_SYS_CLONE diff --git a/arch/arm64/include/asm/unistd32.h b/arch/arm64/include/asm/unistd32.h index 99ffcafc736c..0f49cdb180dd 100644 --- a/arch/arm64/include/asm/unistd32.h +++ b/arch/arm64/include/asm/unistd32.h @@ -901,6 +901,8 @@ __SYSCALL(__NR_landlock_create_ruleset, sys_landlock_create_ruleset) __SYSCALL(__NR_landlock_add_rule, sys_landlock_add_rule) #define __NR_landlock_restrict_self 446 __SYSCALL(__NR_landlock_restrict_self, sys_landlock_restrict_self) +#define __NR_process_mrelease 448 +__SYSCALL(__NR_process_mrelease, sys_process_mrelease) /* * Please add new compat syscalls above this comment and update diff --git a/arch/ia64/kernel/syscalls/syscall.tbl b/arch/ia64/kernel/syscalls/syscall.tbl index 6d07742c57b8..9bf45f2be966 100644 --- a/arch/ia64/kernel/syscalls/syscall.tbl +++ b/arch/ia64/kernel/syscalls/syscall.tbl @@ -367,3 +367,5 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 common process_mrelease sys_process_mrelease diff --git a/arch/m68k/kernel/syscalls/syscall.tbl b/arch/m68k/kernel/syscalls/syscall.tbl index 541bc1b3a8f9..f1f98ee6c82d 100644 --- a/arch/m68k/kernel/syscalls/syscall.tbl +++ b/arch/m68k/kernel/syscalls/syscall.tbl @@ -446,3 +446,5 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 common process_mrelease sys_process_mrelease diff --git a/arch/microblaze/kernel/syscalls/syscall.tbl b/arch/microblaze/kernel/syscalls/syscall.tbl index a176faca2927..da49ddd4bb54 100644 --- a/arch/microblaze/kernel/syscalls/syscall.tbl +++ b/arch/microblaze/kernel/syscalls/syscall.tbl @@ -452,3 +452,5 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 common process_mrelease sys_process_mrelease diff --git a/arch/mips/kernel/syscalls/syscall_n32.tbl b/arch/mips/kernel/syscalls/syscall_n32.tbl index c2d2e19abea8..56c8d3cf42ed 100644 --- a/arch/mips/kernel/syscalls/syscall_n32.tbl +++ b/arch/mips/kernel/syscalls/syscall_n32.tbl @@ -385,3 +385,5 @@ 444 n32 landlock_create_ruleset sys_landlock_create_ruleset 445 n32 landlock_add_rule sys_landlock_add_rule 446 n32 landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 n32 process_mrelease sys_process_mrelease diff --git a/arch/mips/kernel/syscalls/syscall_n64.tbl b/arch/mips/kernel/syscalls/syscall_n64.tbl index ac653d08b1ea..1ca7bc337932 100644 --- a/arch/mips/kernel/syscalls/syscall_n64.tbl +++ b/arch/mips/kernel/syscalls/syscall_n64.tbl @@ -361,3 +361,5 @@ 444 n64 landlock_create_ruleset sys_landlock_create_ruleset 445 n64 landlock_add_rule sys_landlock_add_rule 446 n64 landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 n64 process_mrelease sys_process_mrelease diff --git a/arch/mips/kernel/syscalls/syscall_o32.tbl b/arch/mips/kernel/syscalls/syscall_o32.tbl index 253f2cd70b6b..fd3a9df60ec2 100644 --- a/arch/mips/kernel/syscalls/syscall_o32.tbl +++ b/arch/mips/kernel/syscalls/syscall_o32.tbl @@ -434,3 +434,5 @@ 444 o32 landlock_create_ruleset sys_landlock_create_ruleset 445 o32 landlock_add_rule sys_landlock_add_rule 446 o32 landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 o32 process_mrelease sys_process_mrelease diff --git a/arch/parisc/kernel/syscalls/syscall.tbl b/arch/parisc/kernel/syscalls/syscall.tbl index e26187b9ab87..040df1b7a589 100644 --- a/arch/parisc/kernel/syscalls/syscall.tbl +++ b/arch/parisc/kernel/syscalls/syscall.tbl @@ -444,3 +444,5 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 common process_mrelease sys_process_mrelease diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl index aef2a290e71a..d8ebd7d37c0f 100644 --- a/arch/powerpc/kernel/syscalls/syscall.tbl +++ b/arch/powerpc/kernel/syscalls/syscall.tbl @@ -526,3 +526,5 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 common process_mrelease sys_process_mrelease diff --git a/arch/s390/kernel/syscalls/syscall.tbl b/arch/s390/kernel/syscalls/syscall.tbl index 64d51ab5a8b4..57233ace30cb 100644 --- a/arch/s390/kernel/syscalls/syscall.tbl +++ b/arch/s390/kernel/syscalls/syscall.tbl @@ -449,3 +449,5 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 common process_mrelease sys_process_mrelease sys_process_mrelease diff --git a/arch/sh/kernel/syscalls/syscall.tbl b/arch/sh/kernel/syscalls/syscall.tbl index e0a70be77d84..2f6e95eb4690 100644 --- a/arch/sh/kernel/syscalls/syscall.tbl +++ b/arch/sh/kernel/syscalls/syscall.tbl @@ -449,3 +449,5 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 common process_mrelease sys_process_mrelease diff --git a/arch/sparc/kernel/syscalls/syscall.tbl b/arch/sparc/kernel/syscalls/syscall.tbl index 603f5a821502..42fc2906215d 100644 --- a/arch/sparc/kernel/syscalls/syscall.tbl +++ b/arch/sparc/kernel/syscalls/syscall.tbl @@ -492,3 +492,5 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 common process_mrelease sys_process_mrelease diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl index ce763a12311c..661a03bcfbd1 100644 --- a/arch/x86/entry/syscalls/syscall_32.tbl +++ b/arch/x86/entry/syscalls/syscall_32.tbl @@ -452,3 +452,4 @@ 445 i386 landlock_add_rule sys_landlock_add_rule 446 i386 landlock_restrict_self sys_landlock_restrict_self 447 i386 memfd_secret sys_memfd_secret +448 i386 process_mrelease sys_process_mrelease diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl index f6b57799c1ea..807b6a1de8e8 100644 --- a/arch/x86/entry/syscalls/syscall_64.tbl +++ b/arch/x86/entry/syscalls/syscall_64.tbl @@ -369,6 +369,7 @@ 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self 447 common memfd_secret sys_memfd_secret +448 common process_mrelease sys_process_mrelease # # Due to a historical design error, certain syscalls are numbered differently diff --git a/arch/xtensa/kernel/syscalls/syscall.tbl b/arch/xtensa/kernel/syscalls/syscall.tbl index 235d67d6ceb4..f4384951f393 100644 --- a/arch/xtensa/kernel/syscalls/syscall.tbl +++ b/arch/xtensa/kernel/syscalls/syscall.tbl @@ -417,3 +417,5 @@ 444 common landlock_create_ruleset sys_landlock_create_ruleset 445 common landlock_add_rule sys_landlock_add_rule 446 common landlock_restrict_self sys_landlock_restrict_self +# 447 reserved for memfd_secret +448 common process_mrelease sys_process_mrelease diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index 69c9a7010081..00bc170a50f0 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -915,6 +915,7 @@ asmlinkage long sys_mincore(unsigned long start, size_t len, asmlinkage long sys_madvise(unsigned long start, size_t len, int behavior); asmlinkage long sys_process_madvise(int pidfd, const struct iovec __user *vec, size_t vlen, int behavior, unsigned int flags); +asmlinkage long sys_process_mrelease(int pidfd, unsigned int flags); asmlinkage long sys_remap_file_pages(unsigned long start, unsigned long size, unsigned long prot, unsigned long pgoff, unsigned long flags); diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index a9d6fcd95f42..14c8fe863c6d 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -877,9 +877,11 @@ __SYSCALL(__NR_landlock_restrict_self, sys_landlock_restrict_self) #define __NR_memfd_secret 447 __SYSCALL(__NR_memfd_secret, sys_memfd_secret) #endif +#define __NR_process_mrelease 448 +__SYSCALL(__NR_process_mrelease, sys_process_mrelease) #undef __NR_syscalls -#define __NR_syscalls 448 +#define __NR_syscalls 449 /* * 32 bit systems traditionally used different diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c index 30971b1dd4a9..18a9c2cde767 100644 --- a/kernel/sys_ni.c +++ b/kernel/sys_ni.c @@ -289,6 +289,7 @@ COND_SYSCALL(munlockall); COND_SYSCALL(mincore); COND_SYSCALL(madvise); COND_SYSCALL(process_madvise); +COND_SYSCALL(process_mrelease); COND_SYSCALL(remap_file_pages); COND_SYSCALL(mbind); COND_SYSCALL_COMPAT(mbind); -- 2.32.0.432.gabb21c7263-goog ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-07-23 1:14 [PATCH v3 1/2] mm: introduce process_mrelease system call Suren Baghdasaryan 2021-07-23 1:14 ` [PATCH v3 2/2] mm: wire up syscall process_mrelease Suren Baghdasaryan @ 2021-07-23 2:03 ` Shakeel Butt [not found] ` <CAJuCfpFZeQez77CB7odfaSpi3JcLQ_Nz0WvDTsra1VPoA-j7sg@mail.gmail.com> 2021-07-26 8:20 ` Michal Hocko 1 sibling, 2 replies; 18+ messages in thread From: Shakeel Butt @ 2021-07-23 2:03 UTC (permalink / raw) To: Suren Baghdasaryan Cc: Andrew Morton, Michal Hocko, Michal Hocko, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, jengelh, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Thu, Jul 22, 2021 at 6:14 PM Suren Baghdasaryan <surenb@google.com> wrote: > [...] > + > + mmap_read_lock(mm); How about mmap_read_trylock(mm) and return -EAGAIN on failure? > + if (!__oom_reap_task_mm(mm)) > + ret = -EAGAIN; > + mmap_read_unlock(mm); > + ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <CAJuCfpFZeQez77CB7odfaSpi3JcLQ_Nz0WvDTsra1VPoA-j7sg@mail.gmail.com>]
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call [not found] ` <CAJuCfpFZeQez77CB7odfaSpi3JcLQ_Nz0WvDTsra1VPoA-j7sg@mail.gmail.com> @ 2021-07-23 6:20 ` Michal Hocko [not found] ` <CAJuCfpGSZwVgZ=FxhCV-uC_mzC7O-v-3k3tm-F6kOB7WM9t9tw@mail.gmail.com> 2021-07-23 13:40 ` Shakeel Butt 0 siblings, 2 replies; 18+ messages in thread From: Michal Hocko @ 2021-07-23 6:20 UTC (permalink / raw) To: Suren Baghdasaryan Cc: Shakeel Butt, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Thu 22-07-21 21:47:56, Suren Baghdasaryan wrote: > On Thu, Jul 22, 2021, 7:04 PM Shakeel Butt <shakeelb@google.com> wrote: > > > On Thu, Jul 22, 2021 at 6:14 PM Suren Baghdasaryan <surenb@google.com> > > wrote: > > > > > [...] > > > + > > > + mmap_read_lock(mm); > > > > How about mmap_read_trylock(mm) and return -EAGAIN on failure? > > > > That sounds like a good idea. Thanks! I'll add that in the next respin. Why is that a good idea? Can you do anything meaningful about the failure other than immediately retry the syscall and hope for the best? -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <CAJuCfpGSZwVgZ=FxhCV-uC_mzC7O-v-3k3tm-F6kOB7WM9t9tw@mail.gmail.com>]
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call [not found] ` <CAJuCfpGSZwVgZ=FxhCV-uC_mzC7O-v-3k3tm-F6kOB7WM9t9tw@mail.gmail.com> @ 2021-07-23 8:15 ` David Hildenbrand 2021-07-23 8:18 ` Suren Baghdasaryan 2021-07-23 8:53 ` Michal Hocko 1 sibling, 1 reply; 18+ messages in thread From: David Hildenbrand @ 2021-07-23 8:15 UTC (permalink / raw) To: Suren Baghdasaryan, Michal Hocko Cc: Shakeel Butt, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On 23.07.21 10:11, Suren Baghdasaryan wrote: > > > On Thu, Jul 22, 2021, 11:20 PM Michal Hocko <mhocko@suse.com > <mailto:mhocko@suse.com>> wrote: > > On Thu 22-07-21 21:47:56, Suren Baghdasaryan wrote: > > On Thu, Jul 22, 2021, 7:04 PM Shakeel Butt <shakeelb@google.com > <mailto:shakeelb@google.com>> wrote: > > > > > On Thu, Jul 22, 2021 at 6:14 PM Suren Baghdasaryan > <surenb@google.com <mailto:surenb@google.com>> > > > wrote: > > > > > > > [...] > > > > + > > > > + mmap_read_lock(mm); > > > > > > How about mmap_read_trylock(mm) and return -EAGAIN on failure? > > > > > > > That sounds like a good idea. Thanks! I'll add that in the next > respin. > > Why is that a good idea? Can you do anything meaningful about the > failure other than immediately retry the syscall and hope for the best? > > > I was thinking if this syscall implements "best effort without blocking" > approach then for a more strict usage user can simply retry. However > retrying means issuing another syscall, so additional overhead... > I guess such "best effort" approach would be unusual for a syscall, so > maybe we can keep it as it is now and if such "do not block" mode is > needed we can use flags to implement it later? The process is dying, so I am not sure what we are trying to optimize here in respect to locking ... -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-07-23 8:15 ` David Hildenbrand @ 2021-07-23 8:18 ` Suren Baghdasaryan 0 siblings, 0 replies; 18+ messages in thread From: Suren Baghdasaryan @ 2021-07-23 8:18 UTC (permalink / raw) To: David Hildenbrand Cc: Michal Hocko, Shakeel Butt, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Fri, Jul 23, 2021 at 1:15 AM David Hildenbrand <david@redhat.com> wrote: > > On 23.07.21 10:11, Suren Baghdasaryan wrote: > > > > > > On Thu, Jul 22, 2021, 11:20 PM Michal Hocko <mhocko@suse.com > > <mailto:mhocko@suse.com>> wrote: > > > > On Thu 22-07-21 21:47:56, Suren Baghdasaryan wrote: > > > On Thu, Jul 22, 2021, 7:04 PM Shakeel Butt <shakeelb@google.com > > <mailto:shakeelb@google.com>> wrote: > > > > > > > On Thu, Jul 22, 2021 at 6:14 PM Suren Baghdasaryan > > <surenb@google.com <mailto:surenb@google.com>> > > > > wrote: > > > > > > > > > [...] > > > > > + > > > > > + mmap_read_lock(mm); > > > > > > > > How about mmap_read_trylock(mm) and return -EAGAIN on failure? > > > > > > > > > > That sounds like a good idea. Thanks! I'll add that in the next > > respin. > > > > Why is that a good idea? Can you do anything meaningful about the > > failure other than immediately retry the syscall and hope for the best? > > > > > > I was thinking if this syscall implements "best effort without blocking" > > approach then for a more strict usage user can simply retry. However > > retrying means issuing another syscall, so additional overhead... > > I guess such "best effort" approach would be unusual for a syscall, so > > maybe we can keep it as it is now and if such "do not block" mode is > > needed we can use flags to implement it later? > > The process is dying, so I am not sure what we are trying to optimize > here in respect to locking ... Trying not to block the caller, which is likely a system health monitoring process. However, if not blocking is important, it can issue this syscall from a separate thread... Let's scratch that "do not block" mode and keep it simple as it is now. > > > -- > Thanks, > > David / dhildenb > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call [not found] ` <CAJuCfpGSZwVgZ=FxhCV-uC_mzC7O-v-3k3tm-F6kOB7WM9t9tw@mail.gmail.com> 2021-07-23 8:15 ` David Hildenbrand @ 2021-07-23 8:53 ` Michal Hocko 2021-07-23 13:46 ` Shakeel Butt 1 sibling, 1 reply; 18+ messages in thread From: Michal Hocko @ 2021-07-23 8:53 UTC (permalink / raw) To: Suren Baghdasaryan Cc: Shakeel Butt, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Fri 23-07-21 01:11:51, Suren Baghdasaryan wrote: > On Thu, Jul 22, 2021, 11:20 PM Michal Hocko <mhocko@suse.com> wrote: > > > On Thu 22-07-21 21:47:56, Suren Baghdasaryan wrote: > > > On Thu, Jul 22, 2021, 7:04 PM Shakeel Butt <shakeelb@google.com> wrote: > > > > > > > On Thu, Jul 22, 2021 at 6:14 PM Suren Baghdasaryan <surenb@google.com> > > > > wrote: > > > > > > > > > [...] > > > > > + > > > > > + mmap_read_lock(mm); > > > > > > > > How about mmap_read_trylock(mm) and return -EAGAIN on failure? > > > > > > > > > > That sounds like a good idea. Thanks! I'll add that in the next respin. > > > > Why is that a good idea? Can you do anything meaningful about the > > failure other than immediately retry the syscall and hope for the best? > > > > I was thinking if this syscall implements "best effort without blocking" > approach then for a more strict usage user can simply retry. I do not think we really want to promise non blocking behavior at this stage unless that is absolutely necessary. The current implementation goes an extra mile to not block but I wouldn't carve it into stone via userspace expectations. > However > retrying means issuing another syscall, so additional overhead... > I guess such "best effort" approach would be unusual for a syscall, so > maybe we can keep it as it is now and if such "do not block" mode is needed > we can use flags to implement it later? Yeah, an explicit opt-in via flags would be an option if that turns out to be really necessary. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-07-23 8:53 ` Michal Hocko @ 2021-07-23 13:46 ` Shakeel Butt 2021-07-23 16:08 ` Suren Baghdasaryan 0 siblings, 1 reply; 18+ messages in thread From: Shakeel Butt @ 2021-07-23 13:46 UTC (permalink / raw) To: Michal Hocko Cc: Suren Baghdasaryan, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Fri, Jul 23, 2021 at 1:53 AM Michal Hocko <mhocko@suse.com> wrote: > [...] > > However > > retrying means issuing another syscall, so additional overhead... > > I guess such "best effort" approach would be unusual for a syscall, so > > maybe we can keep it as it is now and if such "do not block" mode is needed > > we can use flags to implement it later? > > Yeah, an explicit opt-in via flags would be an option if that turns out > to be really necessary. > I am fine with keeping it as it is but we do need the non-blocking option (via flags) to enable userspace to act more aggressively. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-07-23 13:46 ` Shakeel Butt @ 2021-07-23 16:08 ` Suren Baghdasaryan 2021-07-23 17:00 ` Shakeel Butt 0 siblings, 1 reply; 18+ messages in thread From: Suren Baghdasaryan @ 2021-07-23 16:08 UTC (permalink / raw) To: Shakeel Butt Cc: Michal Hocko, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Fri, Jul 23, 2021 at 6:46 AM Shakeel Butt <shakeelb@google.com> wrote: > > On Fri, Jul 23, 2021 at 1:53 AM Michal Hocko <mhocko@suse.com> wrote: > > > [...] > > > However > > > retrying means issuing another syscall, so additional overhead... > > > I guess such "best effort" approach would be unusual for a syscall, so > > > maybe we can keep it as it is now and if such "do not block" mode is needed > > > we can use flags to implement it later? > > > > Yeah, an explicit opt-in via flags would be an option if that turns out > > to be really necessary. > > > > I am fine with keeping it as it is but we do need the non-blocking > option (via flags) to enable userspace to act more aggressively. I think you want to check memory conditions shortly after issuing kill/reap requests irrespective of mmap_sem contention. The reason is that even when memory release is not blocked, allocations from other processes might consume memory faster than we release it. For example, in Android we issue kill and start waiting on pidfd for its death notification. As soon as the process is dead we reassess the situation and possibly kill again. If the process is not dead within a configurable timeout we check conditions again and might issue more kill requests (IOW our wait for the process to die has a timeout). If process_mrelease() is blocked on mmap_sem, we might timeout like this. I imagine that a non-blocking option for process_mrelease() would not really change this logic. Adding such an option is trivial but I would like to make sure it's indeed useful. Maybe after the syscall is in place you can experiment with it and see if such an option would really change the way you use it? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-07-23 16:08 ` Suren Baghdasaryan @ 2021-07-23 17:00 ` Shakeel Butt 2021-07-26 7:27 ` Michal Hocko 0 siblings, 1 reply; 18+ messages in thread From: Shakeel Butt @ 2021-07-23 17:00 UTC (permalink / raw) To: Suren Baghdasaryan Cc: Michal Hocko, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Fri, Jul 23, 2021 at 9:09 AM Suren Baghdasaryan <surenb@google.com> wrote: > > On Fri, Jul 23, 2021 at 6:46 AM Shakeel Butt <shakeelb@google.com> wrote: > > > > On Fri, Jul 23, 2021 at 1:53 AM Michal Hocko <mhocko@suse.com> wrote: > > > > > [...] > > > > However > > > > retrying means issuing another syscall, so additional overhead... > > > > I guess such "best effort" approach would be unusual for a syscall, so > > > > maybe we can keep it as it is now and if such "do not block" mode is needed > > > > we can use flags to implement it later? > > > > > > Yeah, an explicit opt-in via flags would be an option if that turns out > > > to be really necessary. > > > > > > > I am fine with keeping it as it is but we do need the non-blocking > > option (via flags) to enable userspace to act more aggressively. > > I think you want to check memory conditions shortly after issuing > kill/reap requests irrespective of mmap_sem contention. The reason is > that even when memory release is not blocked, allocations from other > processes might consume memory faster than we release it. For example, > in Android we issue kill and start waiting on pidfd for its death > notification. As soon as the process is dead we reassess the situation > and possibly kill again. If the process is not dead within a > configurable timeout we check conditions again and might issue more > kill requests (IOW our wait for the process to die has a timeout). If > process_mrelease() is blocked on mmap_sem, we might timeout like this. > I imagine that a non-blocking option for process_mrelease() would not > really change this logic. On a containerized system, killing a job requires killing multiple processes and then process_mrelease() them. Now there is cgroup.kill to kill all the processes in a cgroup tree but we would still need to process_mrelease() all the processes in that tree. There is a chance that we get stuck in reaping the early process. Making process_mrelease() non-blocking will enable the userspace to go to other processes in the list. An alternative would be to have a cgroup specific interface for reaping similar to cgroup.kill. > Adding such an option is trivial but I would like to make sure it's > indeed useful. Maybe after the syscall is in place you can experiment > with it and see if such an option would really change the way you use > it? SGTM. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-07-23 17:00 ` Shakeel Butt @ 2021-07-26 7:27 ` Michal Hocko 2021-07-26 13:43 ` Shakeel Butt 0 siblings, 1 reply; 18+ messages in thread From: Michal Hocko @ 2021-07-26 7:27 UTC (permalink / raw) To: Shakeel Butt Cc: Suren Baghdasaryan, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Fri 23-07-21 10:00:26, Shakeel Butt wrote: > On Fri, Jul 23, 2021 at 9:09 AM Suren Baghdasaryan <surenb@google.com> wrote: > > > > On Fri, Jul 23, 2021 at 6:46 AM Shakeel Butt <shakeelb@google.com> wrote: > > > > > > On Fri, Jul 23, 2021 at 1:53 AM Michal Hocko <mhocko@suse.com> wrote: > > > > > > > [...] > > > > > However > > > > > retrying means issuing another syscall, so additional overhead... > > > > > I guess such "best effort" approach would be unusual for a syscall, so > > > > > maybe we can keep it as it is now and if such "do not block" mode is needed > > > > > we can use flags to implement it later? > > > > > > > > Yeah, an explicit opt-in via flags would be an option if that turns out > > > > to be really necessary. > > > > > > > > > > I am fine with keeping it as it is but we do need the non-blocking > > > option (via flags) to enable userspace to act more aggressively. > > > > I think you want to check memory conditions shortly after issuing > > kill/reap requests irrespective of mmap_sem contention. The reason is > > that even when memory release is not blocked, allocations from other > > processes might consume memory faster than we release it. For example, > > in Android we issue kill and start waiting on pidfd for its death > > notification. As soon as the process is dead we reassess the situation > > and possibly kill again. If the process is not dead within a > > configurable timeout we check conditions again and might issue more > > kill requests (IOW our wait for the process to die has a timeout). If > > process_mrelease() is blocked on mmap_sem, we might timeout like this. > > I imagine that a non-blocking option for process_mrelease() would not > > really change this logic. > > On a containerized system, killing a job requires killing multiple > processes and then process_mrelease() them. Now there is cgroup.kill > to kill all the processes in a cgroup tree but we would still need to > process_mrelease() all the processes in that tree. Is process_mrelease on all of them really necessary? I thought that the primary reason for the call is to guarantee a forward progress in cases where the userspace OOM victim cannot die on SIGKILL. That should be more an exception than a normal case, no? > There is a chance > that we get stuck in reaping the early process. Making > process_mrelease() non-blocking will enable the userspace to go to > other processes in the list. I do agree that allowing (guanrateed) non-blocking behavior is nice but it is also a rather strong promise. There is some memory that cannot be released by the oom reaper currently because there are locks involved (e.g. mlocked memory or memory areas backed by blocking notifiers). I can imagine some users of this api would rather block and make sure to release the memory rather than skip over it. So if anything this has to be an opt in with a big fat warning that the behavior of the kernel wrt to releasable memory can vary due to all sorts of implementation details. > An alternative would be to have a cgroup specific interface for > reaping similar to cgroup.kill. Could you elaborate? -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-07-26 7:27 ` Michal Hocko @ 2021-07-26 13:43 ` Shakeel Butt 2021-08-02 19:53 ` Suren Baghdasaryan 0 siblings, 1 reply; 18+ messages in thread From: Shakeel Butt @ 2021-07-26 13:43 UTC (permalink / raw) To: Michal Hocko Cc: Suren Baghdasaryan, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Mon, Jul 26, 2021 at 12:27 AM Michal Hocko <mhocko@suse.com> wrote: > [...] > > Is process_mrelease on all of them really necessary? I thought that the > primary reason for the call is to guarantee a forward progress in cases > where the userspace OOM victim cannot die on SIGKILL. That should be > more an exception than a normal case, no? > I am thinking of using this API in this way: On user-defined OOM condition, kill a job/cgroup and unconditionally reap all of its processes. Keep monitoring the situation and if it does not improve go for another kill and reap. I can add additional logic in between kill and reap to see if reap is necessary but unconditionally reaping is more simple. > > > An alternative would be to have a cgroup specific interface for > > reaping similar to cgroup.kill. > > Could you elaborate? > I mentioned this in [1] where I was thinking if it makes sense to overload cgroup.kill to also add the SIGKILLed processes in oom_reaper_list. The downside would be that there will be one thread doing the reaping and the syscall approach allows userspace to reap in multiple threads. I think for now, I would go with whatever Suren is proposing and we can always add more stuff if need arises. [1] https://lore.kernel.org/containers/CALvZod4jsb6bFzTOS4ZRAJGAzBru0oWanAhezToprjACfGm+ew@mail.gmail.com/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-07-26 13:43 ` Shakeel Butt @ 2021-08-02 19:53 ` Suren Baghdasaryan 2021-08-02 20:05 ` Shakeel Butt 0 siblings, 1 reply; 18+ messages in thread From: Suren Baghdasaryan @ 2021-08-02 19:53 UTC (permalink / raw) To: Shakeel Butt Cc: Michal Hocko, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Mon, Jul 26, 2021 at 6:44 AM Shakeel Butt <shakeelb@google.com> wrote: > > On Mon, Jul 26, 2021 at 12:27 AM Michal Hocko <mhocko@suse.com> wrote: > > > [...] > > > > Is process_mrelease on all of them really necessary? I thought that the > > primary reason for the call is to guarantee a forward progress in cases > > where the userspace OOM victim cannot die on SIGKILL. That should be > > more an exception than a normal case, no? > > > > I am thinking of using this API in this way: On user-defined OOM > condition, kill a job/cgroup and unconditionally reap all of its > processes. Keep monitoring the situation and if it does not improve go > for another kill and reap. > > I can add additional logic in between kill and reap to see if reap is > necessary but unconditionally reaping is more simple. > > > > > > An alternative would be to have a cgroup specific interface for > > > reaping similar to cgroup.kill. > > > > Could you elaborate? > > > > I mentioned this in [1] where I was thinking if it makes sense to > overload cgroup.kill to also add the SIGKILLed processes in > oom_reaper_list. The downside would be that there will be one thread > doing the reaping and the syscall approach allows userspace to reap in > multiple threads. I think for now, I would go with whatever Suren is > proposing and we can always add more stuff if need arises. > > [1] https://lore.kernel.org/containers/CALvZod4jsb6bFzTOS4ZRAJGAzBru0oWanAhezToprjACfGm+ew@mail.gmail.com/ Hi Folks, So far I don't think there was any request for further changes. Anything else you would want me to address or are we in a good shape wrt this feature? If so, would people who had a chance to review this patchset be willing to endorse it with their Reviewed-by or Acked-by? Thanks, Suren. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-08-02 19:53 ` Suren Baghdasaryan @ 2021-08-02 20:05 ` Shakeel Butt 2021-08-02 20:08 ` Suren Baghdasaryan 0 siblings, 1 reply; 18+ messages in thread From: Shakeel Butt @ 2021-08-02 20:05 UTC (permalink / raw) To: Suren Baghdasaryan Cc: Michal Hocko, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Mon, Aug 2, 2021 at 12:54 PM Suren Baghdasaryan <surenb@google.com> wrote: > > On Mon, Jul 26, 2021 at 6:44 AM Shakeel Butt <shakeelb@google.com> wrote: > > > > On Mon, Jul 26, 2021 at 12:27 AM Michal Hocko <mhocko@suse.com> wrote: > > > > > [...] > > > > > > Is process_mrelease on all of them really necessary? I thought that the > > > primary reason for the call is to guarantee a forward progress in cases > > > where the userspace OOM victim cannot die on SIGKILL. That should be > > > more an exception than a normal case, no? > > > > > > > I am thinking of using this API in this way: On user-defined OOM > > condition, kill a job/cgroup and unconditionally reap all of its > > processes. Keep monitoring the situation and if it does not improve go > > for another kill and reap. > > > > I can add additional logic in between kill and reap to see if reap is > > necessary but unconditionally reaping is more simple. > > > > > > > > > An alternative would be to have a cgroup specific interface for > > > > reaping similar to cgroup.kill. > > > > > > Could you elaborate? > > > > > > > I mentioned this in [1] where I was thinking if it makes sense to > > overload cgroup.kill to also add the SIGKILLed processes in > > oom_reaper_list. The downside would be that there will be one thread > > doing the reaping and the syscall approach allows userspace to reap in > > multiple threads. I think for now, I would go with whatever Suren is > > proposing and we can always add more stuff if need arises. > > > > [1] https://lore.kernel.org/containers/CALvZod4jsb6bFzTOS4ZRAJGAzBru0oWanAhezToprjACfGm+ew@mail.gmail.com/ > > Hi Folks, > So far I don't think there was any request for further changes. > Anything else you would want me to address or are we in a good shape > wrt this feature? > If so, would people who had a chance to review this patchset be > willing to endorse it with their Reviewed-by or Acked-by? I think with Michal's suggestion to use a killable mmap lock, at least I am good with the patch. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-08-02 20:05 ` Shakeel Butt @ 2021-08-02 20:08 ` Suren Baghdasaryan 2021-08-02 22:16 ` Suren Baghdasaryan 0 siblings, 1 reply; 18+ messages in thread From: Suren Baghdasaryan @ 2021-08-02 20:08 UTC (permalink / raw) To: Shakeel Butt Cc: Michal Hocko, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Mon, Aug 2, 2021 at 1:05 PM Shakeel Butt <shakeelb@google.com> wrote: > > On Mon, Aug 2, 2021 at 12:54 PM Suren Baghdasaryan <surenb@google.com> wrote: > > > > On Mon, Jul 26, 2021 at 6:44 AM Shakeel Butt <shakeelb@google.com> wrote: > > > > > > On Mon, Jul 26, 2021 at 12:27 AM Michal Hocko <mhocko@suse.com> wrote: > > > > > > > [...] > > > > > > > > Is process_mrelease on all of them really necessary? I thought that the > > > > primary reason for the call is to guarantee a forward progress in cases > > > > where the userspace OOM victim cannot die on SIGKILL. That should be > > > > more an exception than a normal case, no? > > > > > > > > > > I am thinking of using this API in this way: On user-defined OOM > > > condition, kill a job/cgroup and unconditionally reap all of its > > > processes. Keep monitoring the situation and if it does not improve go > > > for another kill and reap. > > > > > > I can add additional logic in between kill and reap to see if reap is > > > necessary but unconditionally reaping is more simple. > > > > > > > > > > > > An alternative would be to have a cgroup specific interface for > > > > > reaping similar to cgroup.kill. > > > > > > > > Could you elaborate? > > > > > > > > > > I mentioned this in [1] where I was thinking if it makes sense to > > > overload cgroup.kill to also add the SIGKILLed processes in > > > oom_reaper_list. The downside would be that there will be one thread > > > doing the reaping and the syscall approach allows userspace to reap in > > > multiple threads. I think for now, I would go with whatever Suren is > > > proposing and we can always add more stuff if need arises. > > > > > > [1] https://lore.kernel.org/containers/CALvZod4jsb6bFzTOS4ZRAJGAzBru0oWanAhezToprjACfGm+ew@mail.gmail.com/ > > > > Hi Folks, > > So far I don't think there was any request for further changes. > > Anything else you would want me to address or are we in a good shape > > wrt this feature? > > If so, would people who had a chance to review this patchset be > > willing to endorse it with their Reviewed-by or Acked-by? > > I think with Michal's suggestion to use a killable mmap lock, at least > I am good with the patch. Ah, yes. Thanks for pointing this out! I'll replace mmap_read_lock() with mmap_read_lock_killable(). Will post an updated version later today. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-08-02 20:08 ` Suren Baghdasaryan @ 2021-08-02 22:16 ` Suren Baghdasaryan 0 siblings, 0 replies; 18+ messages in thread From: Suren Baghdasaryan @ 2021-08-02 22:16 UTC (permalink / raw) To: Shakeel Butt Cc: Michal Hocko, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Mon, Aug 2, 2021 at 1:08 PM Suren Baghdasaryan <surenb@google.com> wrote: > > On Mon, Aug 2, 2021 at 1:05 PM Shakeel Butt <shakeelb@google.com> wrote: > > > > On Mon, Aug 2, 2021 at 12:54 PM Suren Baghdasaryan <surenb@google.com> wrote: > > > > > > On Mon, Jul 26, 2021 at 6:44 AM Shakeel Butt <shakeelb@google.com> wrote: > > > > > > > > On Mon, Jul 26, 2021 at 12:27 AM Michal Hocko <mhocko@suse.com> wrote: > > > > > > > > > [...] > > > > > > > > > > Is process_mrelease on all of them really necessary? I thought that the > > > > > primary reason for the call is to guarantee a forward progress in cases > > > > > where the userspace OOM victim cannot die on SIGKILL. That should be > > > > > more an exception than a normal case, no? > > > > > > > > > > > > > I am thinking of using this API in this way: On user-defined OOM > > > > condition, kill a job/cgroup and unconditionally reap all of its > > > > processes. Keep monitoring the situation and if it does not improve go > > > > for another kill and reap. > > > > > > > > I can add additional logic in between kill and reap to see if reap is > > > > necessary but unconditionally reaping is more simple. > > > > > > > > > > > > > > > An alternative would be to have a cgroup specific interface for > > > > > > reaping similar to cgroup.kill. > > > > > > > > > > Could you elaborate? > > > > > > > > > > > > > I mentioned this in [1] where I was thinking if it makes sense to > > > > overload cgroup.kill to also add the SIGKILLed processes in > > > > oom_reaper_list. The downside would be that there will be one thread > > > > doing the reaping and the syscall approach allows userspace to reap in > > > > multiple threads. I think for now, I would go with whatever Suren is > > > > proposing and we can always add more stuff if need arises. > > > > > > > > [1] https://lore.kernel.org/containers/CALvZod4jsb6bFzTOS4ZRAJGAzBru0oWanAhezToprjACfGm+ew@mail.gmail.com/ > > > > > > Hi Folks, > > > So far I don't think there was any request for further changes. > > > Anything else you would want me to address or are we in a good shape > > > wrt this feature? > > > If so, would people who had a chance to review this patchset be > > > willing to endorse it with their Reviewed-by or Acked-by? > > > > I think with Michal's suggestion to use a killable mmap lock, at least > > I am good with the patch. > > Ah, yes. Thanks for pointing this out! I'll replace mmap_read_lock() > with mmap_read_lock_killable(). Will post an updated version later > today. Posted the next version at https://lore.kernel.org/patchwork/patch/1471403/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-07-23 6:20 ` Michal Hocko [not found] ` <CAJuCfpGSZwVgZ=FxhCV-uC_mzC7O-v-3k3tm-F6kOB7WM9t9tw@mail.gmail.com> @ 2021-07-23 13:40 ` Shakeel Butt 1 sibling, 0 replies; 18+ messages in thread From: Shakeel Butt @ 2021-07-23 13:40 UTC (permalink / raw) To: Michal Hocko Cc: Suren Baghdasaryan, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, Jan Engelhardt, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Thu, Jul 22, 2021 at 11:20 PM Michal Hocko <mhocko@suse.com> wrote: > > On Thu 22-07-21 21:47:56, Suren Baghdasaryan wrote: > > On Thu, Jul 22, 2021, 7:04 PM Shakeel Butt <shakeelb@google.com> wrote: > > > > > On Thu, Jul 22, 2021 at 6:14 PM Suren Baghdasaryan <surenb@google.com> > > > wrote: > > > > > > > [...] > > > > + > > > > + mmap_read_lock(mm); > > > > > > How about mmap_read_trylock(mm) and return -EAGAIN on failure? > > > > > > > That sounds like a good idea. Thanks! I'll add that in the next respin. > > Why is that a good idea? Can you do anything meaningful about the > failure other than immediately retry the syscall and hope for the best? > Yes we can. Based on the situation/impact we can select more victims. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/2] mm: introduce process_mrelease system call 2021-07-23 2:03 ` [PATCH v3 1/2] mm: introduce process_mrelease system call Shakeel Butt [not found] ` <CAJuCfpFZeQez77CB7odfaSpi3JcLQ_Nz0WvDTsra1VPoA-j7sg@mail.gmail.com> @ 2021-07-26 8:20 ` Michal Hocko 1 sibling, 0 replies; 18+ messages in thread From: Michal Hocko @ 2021-07-26 8:20 UTC (permalink / raw) To: Shakeel Butt Cc: Suren Baghdasaryan, Andrew Morton, David Rientjes, Matthew Wilcox, Johannes Weiner, Roman Gushchin, Rik van Riel, Minchan Kim, Christian Brauner, Christoph Hellwig, Oleg Nesterov, David Hildenbrand, Jann Horn, Andy Lutomirski, Christian Brauner, Florian Weimer, jengelh, Tim Murray, Linux API, Linux MM, LKML, kernel-team On Thu 22-07-21 19:03:56, Shakeel Butt wrote: > On Thu, Jul 22, 2021 at 6:14 PM Suren Baghdasaryan <surenb@google.com> wrote: > > > [...] > > + > > + mmap_read_lock(mm); > > How about mmap_read_trylock(mm) and return -EAGAIN on failure? Btw. wether there is a non-blocking variant or not we should use killable waiting to make sure the task calling into this is killable by userspace (e.g. to implement a timeout based approach). -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-08-02 22:16 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-23 1:14 [PATCH v3 1/2] mm: introduce process_mrelease system call Suren Baghdasaryan 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] ` <CAJuCfpFZeQez77CB7odfaSpi3JcLQ_Nz0WvDTsra1VPoA-j7sg@mail.gmail.com> 2021-07-23 6:20 ` Michal Hocko [not found] ` <CAJuCfpGSZwVgZ=FxhCV-uC_mzC7O-v-3k3tm-F6kOB7WM9t9tw@mail.gmail.com> 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
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).