On 06/17/2013 05:30 AM, Mel Gorman wrote:
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@xxxxxxxxxx>
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.
Could we fix that problem by simply allowing page cache
allocations (__GFP_WRITE) to fall back to other zones,
regardless of the zone_reclaim setting?
The ZONE_RECLAIM_LOCKED function seems to break as many
things as it fixes, so replacing it with something else
seems like a worthwhile pursuit...
--
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>