From: Christoph Lameter <cl@linux.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, Li Zefan <lizefan@huawei.com>,
Mel Gorman <mgorman@techsingularity.net>,
David Rientjes <rientjes@google.com>,
Hugh Dickins <hughd@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-api@vger.kernel.org
Subject: Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update
Date: Wed, 17 May 2017 09:48:25 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.20.1705170943090.8714@east.gentwo.org> (raw)
In-Reply-To: <20170517140501.GM18247@dhcp22.suse.cz>
On Wed, 17 May 2017, Michal Hocko wrote:
> > > So how are you going to distinguish VM_FAULT_OOM from an empty mempolicy
> > > case in a raceless way?
> >
> > You dont have to do that if you do not create an empty mempolicy in the
> > first place. The current kernel code avoids that by first allowing access
> > to the new set of nodes and removing the old ones from the set when done.
>
> which is racy and as Vlastimil pointed out. If we simply fail such an
> allocation the failure will go up the call chain until we hit the OOM
> killer due to VM_FAULT_OOM. How would you want to handle that?
The race is where? If you expand the node set during the move of the
application then you are safe in terms of the legacy apps that did not
include static bindings.
If you have screwy things like static mbinds in there then you are
hopelessly lost anyways. You may have moved the process to another set
of nodes but the static bindings may refer to a node no longer
available. Thus the OOM is legitimate.
At least a user space app could inspect
the situation and come up with custom ways of dealing with the mess.
--
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-05-17 14:48 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-11 14:06 [RFC 0/6] cpuset/mempolicies related fixes and cleanups Vlastimil Babka
2017-04-11 14:06 ` [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update Vlastimil Babka
2017-04-11 17:24 ` Christoph Lameter
2017-04-11 19:00 ` Vlastimil Babka
2017-04-12 21:25 ` Christoph Lameter
2017-04-13 6:24 ` Vlastimil Babka
2017-04-14 20:37 ` Christoph Lameter
2017-04-26 8:07 ` Vlastimil Babka
2017-04-30 21:33 ` Christoph Lameter
2017-05-17 9:20 ` Michal Hocko
2017-05-17 13:56 ` Christoph Lameter
2017-05-17 14:05 ` Michal Hocko
2017-05-17 14:48 ` Christoph Lameter [this message]
2017-05-17 14:56 ` Michal Hocko
2017-05-17 15:25 ` Christoph Lameter
2017-05-18 9:08 ` Michal Hocko
2017-05-18 16:57 ` Christoph Lameter
2017-05-18 17:24 ` Michal Hocko
2017-05-18 19:07 ` Christoph Lameter
2017-05-19 7:37 ` Michal Hocko
2017-05-17 15:27 ` Christoph Lameter
2017-05-18 10:03 ` Vlastimil Babka
2017-05-18 17:07 ` Christoph Lameter
2017-05-19 11:27 ` Vlastimil Babka
2017-04-13 5:42 ` Anshuman Khandual
2017-04-13 6:06 ` Vlastimil Babka
2017-04-13 6:07 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 2/6] mm, mempolicy: stop adjusting current->il_next in mpol_rebind_nodemask() Vlastimil Babka
2017-04-11 17:32 ` Christoph Lameter
2017-04-11 19:03 ` Vlastimil Babka
2017-04-12 8:49 ` Vlastimil Babka
2017-04-12 21:16 ` Christoph Lameter
2017-04-12 21:18 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 3/6] mm, page_alloc: pass preferred nid instead of zonelist to allocator Vlastimil Babka
2017-04-11 14:06 ` [RFC 4/6] mm, mempolicy: simplify rebinding mempolicies when updating cpusets Vlastimil Babka
2017-04-11 14:06 ` [RFC 5/6] mm, cpuset: always use seqlock when changing task's nodemask Vlastimil Babka
2017-04-12 8:10 ` Hillf Danton
2017-04-12 8:18 ` Vlastimil Babka
2017-04-11 14:06 ` [RFC 6/6] mm, mempolicy: don't check cpuset seqlock where it doesn't matter Vlastimil Babka
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.20.1705170943090.8714@east.gentwo.org \
--to=cl@linux.com \
--cc=aarcange@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=hughd@google.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
/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