On Thu, Jan 28, 2016 at 10:55:15PM +0100, Michal Hocko wrote:
> On Thu 28-01-16 16:12:40, Johannes Weiner wrote:
> > On Thu, Jan 28, 2016 at 09:11:23PM +0100, Michal Hocko wrote:
> > > On Thu 28-01-16 20:02:04, Andrea Arcangeli wrote:
> > > > It's not immediately apparent if there is a new OOM killer upstream
> > > > logic that would prevent the risk of a second OOM killer invocation
> > > > despite another OOM killing already happened while we were stuck in
> > > > reclaim. In absence of that, the high wmark check would be still
> > > > needed.
> > >
> > > Well, my oom detection rework [1] strives to make the OOM detection more
> > > robust and the retry logic performs the watermark check. So I think the
> > > last attempt is no longer needed after that patch. I will then remove
> > > it.
> >
> > Hm? I don't have the same conclusion from what Andrea said.
> >
> > When you have many allocations racing at the same time, they can all
> > enter __alloc_pages_may_oom() in quick succession. We don't want a
> > cavalcade of OOM kills when one could be enough, so we have to make
> > sure that in between should_alloc_retry() giving up and acquiring the
> > OOM lock nobody else already issued a kill and released enough memory.
> >
> > It's a race window that gets yanked wide open when hundreds of threads
> > race in __alloc_pages_may_oom(). Your patches don't fix that, AFAICS.
>
> Only one task would be allowed to go out_of_memory and all the rest will
> simply fail on oom_lock trylock and return with NULL. Or am I missing
> your point?
Just picture it with mutex_lock() instead of mutex_trylock() and it
becomes obvious why you have to do a locked check before the kill.
The race window is much smaller with the trylock of course, but given
enough threads it's possible that one of the other contenders would
acquire the trylock right after the first task drops it:
first task: 204th task:
!reclaim !reclaim
!should_alloc_retry !should_alloc_retry
oom_trylock
out_of_memory
oom_unlock
oom_trylock
out_of_memory // likely unnecessary
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>