From: Michal Hocko <mhocko@suse.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
thuth@redhat.com, frankja@linux.ibm.com, borntraeger@de.ibm.com,
Ulrich.Weigand@de.ibm.com, heiko.carstens@de.ibm.com,
david@redhat.com, ultrachin@163.com, akpm@linux-foundation.org,
vbabka@suse.cz, brookxu.cn@gmail.com, xiaoggchen@tencent.com,
linuszeng@tencent.com, yihuilu@tencent.com,
daniel.m.jordan@oracle.com, axboe@kernel.dk, legion@kernel.org,
peterz@infradead.org, aarcange@redhat.com, christian@brauner.io,
ebiederm@xmission.com, tglx@linutronix.de
Subject: Re: [RFC v1 0/4] Two alternatives for mm async teardown
Date: Fri, 12 Nov 2021 11:15:51 +0100 [thread overview]
Message-ID: <YY4+1y4+B7s7beJ2@dhcp22.suse.cz> (raw)
In-Reply-To: <20211111095008.264412-1-imbrenda@linux.ibm.com>
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.
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2021-11-12 10:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 9:50 [RFC v1 0/4] Two alternatives for mm async teardown Claudio Imbrenda
2021-11-11 9:50 ` [RFC v1 1/4] add arch mmput hook in exit.c Claudio Imbrenda
2021-11-11 9:50 ` [RFC v1 1/4] exit: add arch mmput hook in exit_mm Claudio Imbrenda
2021-11-11 18:43 ` Eric W. Biederman
2021-11-11 9:50 ` [RFC v1 2/4] kernel/fork.c: implement new process_mmput_async syscall Claudio Imbrenda
2021-11-11 19:20 ` Eric W. Biederman
2021-11-12 9:27 ` Claudio Imbrenda
2021-11-12 9:34 ` Claudio Imbrenda
2021-11-12 14:57 ` Eric W. Biederman
2021-11-12 16:53 ` Claudio Imbrenda
2021-11-15 10:43 ` Michal Hocko
2021-11-11 9:50 ` [RFC v1 3/4] mm: wire up the " Claudio Imbrenda
2021-11-18 18:47 ` kernel test robot
2021-11-11 9:50 ` [RFC v1 4/4] kernel/fork.c: process_mmput_async: stop OOM while freeing memory Claudio Imbrenda
2021-11-12 10:15 ` Michal Hocko [this message]
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=YY4+1y4+B7s7beJ2@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=borntraeger@de.ibm.com \
--cc=brookxu.cn@gmail.com \
--cc=christian@brauner.io \
--cc=daniel.m.jordan@oracle.com \
--cc=david@redhat.com \
--cc=ebiederm@xmission.com \
--cc=frankja@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=legion@kernel.org \
--cc=linuszeng@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=thuth@redhat.com \
--cc=ultrachin@163.com \
--cc=vbabka@suse.cz \
--cc=xiaoggchen@tencent.com \
--cc=yihuilu@tencent.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.