Re: [PATCH 1/3] mm,oom: Move last second allocation to inside the OOM killer.

[Johannes Weiner <hannes@cmpxchg.org>]

On Fri, Dec 01, 2017 at 03:46:34PM +0100, Michal Hocko wrote:
> On Fri 01-12-17 14:33:17, Johannes Weiner wrote:
> > On Sat, Nov 25, 2017 at 07:52:47PM +0900, Tetsuo Handa wrote:
> > > @@ -1068,6 +1071,17 @@ bool out_of_memory(struct oom_control *oc)
> > >  	}
> > >  
> > >  	select_bad_process(oc);
> > > +	/*
> > > +	 * Try really last second allocation attempt after we selected an OOM
> > > +	 * victim, for somebody might have managed to free memory while we were
> > > +	 * selecting an OOM victim which can take quite some time.
> > 
> > Somebody might free some memory right after this attempt fails. OOM
> > can always be a temporary state that resolves on its own.
> > 
> > What keeps us from declaring OOM prematurely is the fact that we
> > already scanned the entire LRU list without success, not last second
> > or last-last second, or REALLY last-last-last-second allocations.
> 
> You are right that this is inherently racy. The point here is, however,
> that the race window between the last check and the kill can be _huge_!

My point is that it's irrelevant. We already sampled the entire LRU
list; compared to that, the delay before the kill is immaterial.

> Another argument is that the allocator itself could have changed its
> allocation capabilities - e.g. become the OOM victim itself since the
> last time it the allocator could have reflected that fact.

Can you outline how this would happen exactly?

> > Nacked-by: Johannes Weiner <hannes@cmpxchg.org>

--
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>