Date:	Wed, 13 Nov 2013 14:16:04 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Johannes Weiner <hannes@...xchg.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...hat.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch] mm, vmscan: abort futile reclaim if we've been oom
 killed

On Wed, 13 Nov 2013, Johannes Weiner wrote:

> > The oom killer is only invoked when reclaim has already failed and it
> > only kills processes if the victim is also oom.  In other words, the oom
> > killer does not select victims when a process tries to allocate from a
> > disjoint cpuset or allocate DMA memory, for example.
> > 
> > Therefore, it's pointless for an oom killed process to continue
> > attempting to reclaim memory in a loop when it has been granted access to
> > memory reserves.  It can simply return to the page allocator and allocate
> > memory.
> 
> On the other hand, finishing reclaim of 32 pages should not be a
> problem.
> 

The reclaim will fail, the only reason current has TIF_MEMDIE set is 
because reclaim has completely failed.

> > If there is a very large number of processes trying to reclaim memory,
> > the cond_resched() in shrink_slab() becomes troublesome since it always
> > forces a schedule to other processes also trying to reclaim memory.
> > Compounded by many reclaim loops, it is possible for a process to sit in
> > do_try_to_free_pages() for a very long time when reclaim is pointless and
> > it could allocate if it just returned to the page allocator.
> 
> "Very large number of processes"
> 
> "sit in do_try_to_free_pages() for a very long time"
> 
> Can you quantify this a bit more?
> 

I have seen kernel logs where ~700 processes are stuck in direct reclaim 
simultaneously or scanning the tasklist in the oom killer only to defer 
because it finds a process that has already been oom killed as is stuck in 
do_try_to_free_pages() making very slow progress because of the number of 
processes trying to reclaim.

I haven't quantified how long the oom killed process sits in 
do_try_to_free_pages() as a result of needlessly looping trying to reclaim 
memory that will ultimately fail.

When the kernel oom kills something in a system oom condition, we hope 
that it will exit quickly because otherwise every other memory allocator 
comes to a grinding halt for as long as it takes to free memory.

> And how common are OOM kills on your setups that you need to optimize
> them on this level?
> 

Very common, the sum of our top-level memcg hardlimits exceeds the amount 
of memory on the system and we very frequently encounter system conditions 
as a regular event.

> It sounds like your problem could be solved by having cond_resched()
> not schedule away from TIF_MEMDIE processes, which would be much
> preferable to oom-killed checks in random places.
> 

I don't know of any other "random places" other than when the oom killed 
process is sitting in reclaim before it is selected as the victim.  Once 
it returns to the page allocator, it will immediately allocate and then be 
able to handle its pending SIGKILL.  The one spot identified where it is 
absolutely pointless to spin is in reclaim since it is virtually 
guaranteed to fail.  This patch fixes that issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists