On Thu 28-01-16 16:12:40, Johannes Weiner wrote:

On Thu, Jan 28, 2016 at 09:11:23PM +0100, Michal Hocko wrote:

quoted

On Thu 28-01-16 20:02:04, Andrea Arcangeli wrote:

quoted

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?

-- 
Michal Hocko
SUSE Labs

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