aboutsummaryrefslogtreecommitdiffstats
path: root/mm/vmscan.c
diff options
context:
space:
mode:
authorNishanth Aravamudan <nacc@us.ibm.com>2008-04-29 03:58:25 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2008-04-29 11:05:58 -0400
commita41f24ea9fd6169b147c53c2392e2887cc1d9247 (patch)
treee6cf79a82f6516a30731f7dec7ed5d76466bb350 /mm/vmscan.c
parentab857d09386661145924c9403792234aeca4bdff (diff)
page allocator: smarter retry of costly-order allocations
Because of page order checks in __alloc_pages(), hugepage (and similarly large order) allocations will not retry unless explicitly marked __GFP_REPEAT. However, the current retry logic is nearly an infinite loop (or until reclaim does no progress whatsoever). For these costly allocations, that seems like overkill and could potentially never terminate. Mel observed that allowing current __GFP_REPEAT semantics for hugepage allocations essentially killed the system. I believe this is because we may continue to reclaim small orders of pages all over, but never have enough to satisfy the hugepage allocation request. This is clearly only a problem for large order allocations, of which hugepages are the most obvious (to me). Modify try_to_free_pages() to indicate how many pages were reclaimed. Use that information in __alloc_pages() to eventually fail a large __GFP_REPEAT allocation when we've reclaimed an order of pages equal to or greater than the allocation's order. This relies on lumpy reclaim functioning as advertised. Due to fragmentation, lumpy reclaim may not be able to free up the order needed in one invocation, so multiple iterations may be requred. In other words, the more fragmented memory is, the more retry attempts __GFP_REPEAT will make (particularly for higher order allocations). This changes the semantics of __GFP_REPEAT subtly, but *only* for allocations > PAGE_ALLOC_COSTLY_ORDER. With this patch, for those size allocations, we will try up to some point (at least 1<<order reclaimed pages), rather than forever (which is the case for allocations <= PAGE_ALLOC_COSTLY_ORDER). This change improves the /proc/sys/vm/nr_hugepages interface with a follow-on patch that makes pool allocations use __GFP_REPEAT. Rather than administrators repeatedly echo'ing a particular value into the sysctl, and forcing reclaim into action manually, this change allows for the sysctl to attempt a reasonable effort itself. Similarly, dynamic pool growth should be more successful under load, as lumpy reclaim can try to free up pages, rather than failing right away. Choosing to reclaim only up to the order of the requested allocation strikes a balance between not failing hugepage allocations and returning to the caller when it's unlikely to every succeed. Because of lumpy reclaim, if we have freed the order requested, hopefully it has been in big chunks and those chunks will allow our allocation to succeed. If that isn't the case after freeing up the current order, I don't think it is likely to succeed in the future, although it is possible given a particular fragmentation pattern. Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> Cc: Andy Whitcroft <apw@shadowen.org> Tested-by: Mel Gorman <mel@csn.ul.ie> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Christoph Lameter <clameter@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/vmscan.c')
-rw-r--r--mm/vmscan.c7
1 files changed, 5 insertions, 2 deletions
diff --git a/mm/vmscan.c b/mm/vmscan.c
index eceac9f9032f..12e8627c9747 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1299,6 +1299,9 @@ static unsigned long shrink_zones(int priority, struct zonelist *zonelist,
1299 * hope that some of these pages can be written. But if the allocating task 1299 * hope that some of these pages can be written. But if the allocating task
1300 * holds filesystem locks which prevent writeout this might not work, and the 1300 * holds filesystem locks which prevent writeout this might not work, and the
1301 * allocation attempt will fail. 1301 * allocation attempt will fail.
1302 *
1303 * returns: 0, if no pages reclaimed
1304 * else, the number of pages reclaimed
1302 */ 1305 */
1303static unsigned long do_try_to_free_pages(struct zonelist *zonelist, 1306static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
1304 struct scan_control *sc) 1307 struct scan_control *sc)
@@ -1347,7 +1350,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
1347 } 1350 }
1348 total_scanned += sc->nr_scanned; 1351 total_scanned += sc->nr_scanned;
1349 if (nr_reclaimed >= sc->swap_cluster_max) { 1352 if (nr_reclaimed >= sc->swap_cluster_max) {
1350 ret = 1; 1353 ret = nr_reclaimed;
1351 goto out; 1354 goto out;
1352 } 1355 }
1353 1356
@@ -1370,7 +1373,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
1370 } 1373 }
1371 /* top priority shrink_caches still had more to do? don't OOM, then */ 1374 /* top priority shrink_caches still had more to do? don't OOM, then */
1372 if (!sc->all_unreclaimable && scan_global_lru(sc)) 1375 if (!sc->all_unreclaimable && scan_global_lru(sc))
1373 ret = 1; 1376 ret = nr_reclaimed;
1374out: 1377out:
1375 /* 1378 /*
1376 * Now that we've scanned all the zones at this priority level, note 1379 * Now that we've scanned all the zones at this priority level, note