Thread (39 messages) 39 messages, 5 authors, 2017-05-19

Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update

From: Michal Hocko <hidden>
Date: 2017-05-18 09:08:55
Also in: linux-api, linux-mm, lkml

On Wed 17-05-17 10:25:09, Cristopher Lameter wrote:
On Wed, 17 May 2017, Michal Hocko wrote:
quoted
quoted
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.
The point is that you do _not_ want such a process to trigger the OOM
because it can cause other processes being killed.
Nope. The OOM in a cpuset gets the process doing the alloc killed. Or what
that changed?

At this point you have messed up royally and nothing is going to rescue
you anyways. OOM or not does not matter anymore. The app will fail.
Not really. If you can trick the system to _think_ that the intersection
between mempolicy and the cpuset is empty then the OOM killer might
trigger an innocent task rather than the one which tricked it into that
situation.
-- 
Michal Hocko
SUSE Labs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help