Re: [patch] vmscan: respect higher order in zone_reclaim()
From: Mel Gorman
Date: Wed Feb 18 2009 - 05:12:19 EST
On Tue, Feb 17, 2009 at 08:48:27PM +0100, Johannes Weiner wrote:
> 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 <mel@xxxxxxxxx>
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.
> Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx>
> Cc: Mel Gorman <mel@xxxxxxxxx>
> ---
> mm/vmscan.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -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;
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/