vmscan: respect higher order in zone_reclaim()

zone_reclaim() already tries to free the requested 2^order pages but doesn't pass the order information into the inner reclaim code.

This prevents lumpy reclaim from happening on higher orders although the caller explicitely asked for that.

Fix it up by initializing the order field of the scan control according to the request.

Signed-off-by Johannes Weiner <[email protected]>

Cc Mel Gorman <[email protected]>

---
 mm/vmscan.c |    1 +
 1 file changed, 1 insertion(+)

mm/vmscan.c +1 -0

@@ -2297,6 +2297,7 @@ static int __zone_reclaim(struct zone *z
 					SWAP_CLUSTER_MAX),
 		.gfp_mask = gfp_mask,
 		.swappiness = vm_swappiness,
+		.order = order,
 		.isolate_pages = isolate_pages_global,
 	};
 	unsigned long slab_reclaimable;

Quoted 9 lines · Johannes Weiner

zone_reclaim() already tries to free the requested 2^order pages but doesn't pass the order information into the inner reclaim code.

This prevents lumpy reclaim from happening on higher orders although the caller explicitely asked for that.

Fix it up by initializing the order field of the scan control according to the request.

I'm fine with the patch but the changelog could have been better. Optionally take this changelog but either way.

Acked-by Mel Gorman <[email protected]>

Optional alternative changelog
==============================

During page allocation, there are two stages of direct reclaim that are applied to each zone in the preferred list. The first stage using zone_reclaim() reclaims unmapped file backed pages and slab pages if over defined limits as these are cheaper to reclaim. The caller specifies the order of the target allocation but the scan control is not being correctly initialised.

The impact is that the correct number of pages are being reclaimed but that lumpy reclaim is not being applied. This increases the chances of a full direct reclaim via try_to_free_pages() is required.

This patch initialises the order field of the scan control as requested by the caller.