mbox series

[RFC,v1,0/4] Two alternatives for mm async teardown

Message ID 20211111095008.264412-1-imbrenda@linux.ibm.com (mailing list archive)
Headers show
Series Two alternatives for mm async teardown | expand

Message

Claudio Imbrenda Nov. 11, 2021, 9:50 a.m. UTC
This RFC series proposes two possible ways for enabling asynchronous mm
teardown.

The first approach, in patch 1, is simply to provide an arch hook in
exit_mm. This has no functional change for archs that don't explicitly
use the hook, and leaves the hard part to arch code (including
accounting, if any).

The second approach, in patches 2 to 4, adds a new syscall to allow an
mm to be asynchronously torn down in the context of another process
(similarly to how process_mrelease works). It also adds an OOM notifier
to prevent the OOM killer from killing processes while the teardown is
in progress.


Claudio Imbrenda (4):
  exit: add arch mmput hook in exit_mm
  kernel/fork.c: implement new process_mmput_async syscall
  mm: wire up the process_mmput_async syscall
  kernel/fork.c: process_mmput_async: stop OOM while freeing memory

 arch/alpha/kernel/syscalls/syscall.tbl      |   2 +
 arch/arm/tools/syscall.tbl                  |   1 +
 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/asm-generic/mmu_context.h           |   4 +
 include/linux/mm_types.h                    |   1 +
 include/linux/syscalls.h                    |   1 +
 include/uapi/asm-generic/unistd.h           |   5 +-
 kernel/exit.c                               |   2 +-
 kernel/fork.c                               | 131 +++++++++++++++++++-
 kernel/sys_ni.c                             |   1 +
 25 files changed, 173 insertions(+), 5 deletions(-)

Comments

Michal Hocko Nov. 12, 2021, 10:15 a.m. UTC | #1
On Thu 11-11-21 10:50:03, Claudio Imbrenda wrote:
> This RFC series proposes two possible ways for enabling asynchronous mm
> teardown.

It would be great to describe an intended usecase here and also explain
why the existing features do not allow the required functionality.

Please also make sure to cc linux-api when adding a new user visible
interface or changing a visible behavior of existing one.

E.g. why cannot you simply create a process outside of the thread group
yet share the mm with your task. Once the other process exits which you
can detect then you just exit that process and do the finall clean up
from that context?

> The first approach, in patch 1, is simply to provide an arch hook in
> exit_mm. This has no functional change for archs that don't explicitly
> use the hook, and leaves the hard part to arch code (including
> accounting, if any).

This is just too vague but I have to say I am not really a fan of hooks
that considerably change the existing behavior.

> The second approach, in patches 2 to 4, adds a new syscall to allow an
> mm to be asynchronously torn down in the context of another process
> (similarly to how process_mrelease works). It also adds an OOM notifier
> to prevent the OOM killer from killing processes while the teardown is
> in progress.

I have to say I do not like oom notifier part at all. You can have
different sources of the OOM (memcg, cpusets or global oom). It is
impossible to tell those appart in the notifier. Not to mention that
memcg oom is explicitly avoiding notifiers altogether.