From: David Rientjes <rientjes@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Michal Hocko" <mhocko@suse.com>,
"Andrea Arcangeli" <aarcange@redhat.com>,
"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
"Paul Mackerras" <paulus@samba.org>,
"Oded Gabbay" <oded.gabbay@gmail.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"David Airlie" <airlied@linux.ie>,
"Joerg Roedel" <joro@8bytes.org>,
"Doug Ledford" <dledford@redhat.com>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Mike Marciniszyn" <mike.marciniszyn@intel.com>,
"Sean Hefty" <sean.hefty@intel.com>,
"Dimitri Sivanich" <sivanich@sgi.com>,
"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks
Date: Mon, 11 Dec 2017 15:09:58 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.10.1712111507520.14765@chino.kir.corp.google.com> (raw)
In-Reply-To: <40828fec-a375-fb90-f4f1-fc647651c2f7@redhat.com>
On Mon, 11 Dec 2017, Paolo Bonzini wrote:
> > Commit 4d4bbd8526a8 ("mm, oom_reaper: skip mm structs with mmu notifiers")
> > prevented the oom reaper from unmapping private anonymous memory with the
> > oom reaper when the oom victim mm had mmu notifiers registered.
> >
> > The rationale is that doing mmu_notifier_invalidate_range_{start,end}()
> > around the unmap_page_range(), which is needed, can block and the oom
> > killer will stall forever waiting for the victim to exit, which may not
> > be possible without reaping.
> >
> > That concern is real, but only true for mmu notifiers that have blockable
> > invalidate_range_{start,end}() callbacks. This patch adds a "flags" field
> > for mmu notifiers that can set a bit to indicate that these callbacks do
> > block.
>
> Why not put the flag in the ops, since the same ops should always be
> either blockable or unblockable?
>
Hi Paolo,
It certainly can be in mmu_notifier_ops, the only rationale for putting
the flags member in mmu_notifier was that it may become generally useful
later for things other than callbacks. I'm indifferent to where it is
placed and will happily move it if that's desired, absent any other
feedback on other parts of the patchset.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-12-11 23:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-11 22:11 David Rientjes
2017-12-11 22:11 ` [patch 2/2] mm, oom: avoid reaping only for mm's " David Rientjes
2017-12-11 22:23 ` [patch 1/2] mm, mmu_notifier: annotate mmu notifiers " Paolo Bonzini
2017-12-11 23:09 ` David Rientjes [this message]
2017-12-12 20:05 ` Dimitri Sivanich
2017-12-12 21:28 ` David Rientjes
2017-12-13 9:34 ` Christian König
2017-12-13 10:26 ` Tetsuo Handa
2017-12-13 10:37 ` Paolo Bonzini
2017-12-14 9:19 ` David Rientjes
2017-12-14 12:46 ` kbuild test robot
2017-12-14 21:30 ` [patch v2 " David Rientjes
2017-12-14 21:31 ` [patch v2 2/2] mm, oom: avoid reaping only for mm's " David Rientjes
2017-12-15 16:35 ` Michal Hocko
2017-12-15 21:46 ` David Rientjes
2017-12-15 8:42 ` [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers " Paolo Bonzini
2017-12-15 12:19 ` Christian König
2017-12-15 13:36 ` Dimitri Sivanich
2017-12-15 16:25 ` Michal Hocko
2017-12-16 6:21 ` Tetsuo Handa
2017-12-16 11:33 ` Michal Hocko
2017-12-15 23:04 ` Andrew Morton
2017-12-16 7:14 ` Tetsuo Handa
2017-12-16 11:36 ` Michal Hocko
2017-12-16 14:45 ` Tetsuo Handa
2017-12-16 9:10 ` Michal Hocko
2018-01-09 21:40 ` [patch -mm] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks fix fix David Rientjes
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=alpine.DEB.2.10.1712111507520.14765@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=aarcange@redhat.com \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=alexander.deucher@amd.com \
--cc=benh@kernel.crashing.org \
--cc=boris.ostrovsky@oracle.com \
--cc=christian.koenig@amd.com \
--cc=dledford@redhat.com \
--cc=jani.nikula@linux.intel.com \
--cc=jglisse@redhat.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mike.marciniszyn@intel.com \
--cc=oded.gabbay@gmail.com \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=sean.hefty@intel.com \
--cc=sivanich@sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox