Re: [PATCH 1/7] mm: remove ZONE_RECLAIM_LOCKED

[Mel Gorman <mgorman@suse.de>]

On Fri, Jun 14, 2013 at 12:16:47PM -0400, Rik van Riel wrote:
> On 06/06/2013 01:37 PM, Rik van Riel wrote:
> >On 06/06/2013 05:04 AM, Mel Gorman wrote:
> >>On Wed, Jun 05, 2013 at 05:10:31PM +0200, Andrea Arcangeli wrote:
> >>>Zone reclaim locked breaks zone_reclaim_mode=1. If more than one
> >>>thread allocates memory at the same time, it forces a premature
> >>>allocation into remote NUMA nodes even when there's plenty of clean
> >>>cache to reclaim in the local nodes.
> >>>
> >>>Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
> >>
> >>Be aware that after this patch is applied that it is possible to have a
> >>situation like this
> >>
> >>1. 4 processes running on node 1
> >>2. Each process tries to allocate 30% of memory
> >>3. Each process reads the full buffer in a loop (stupid, just an example)
> >>
> >>In this situation the processes will continually interfere with each
> >>other until one of them gets migrated to another zone by the scheduler.
> >
> >This is a very good point.
> >
> >Andrea, I suspect we will need some kind of safeguard against
> >this problem.
> 
> Never mind me.
> 
> In __zone_reclaim we set the flags in swap_control so
> we never unmap pages or swap pages out at all by
> default, so this should not be an issue at all.
> 
> In order to get the problem illustrated above, the
> user will have to enable RECLAIM_SWAP through sysfs
> manually.
> 

For the mapped case and the default tuning for zone_reclaim_mode then
yes. If instead of allocating 30% of memory the processes are using using
buffered reads/writes then they'll reach each others page cache pages and
it's a very similar problem.

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