* [patch] vmscan: respect higher order in zone_reclaim()
@ 2009-02-17 19:48 Johannes Weiner
2009-02-18 10:12 ` Mel Gorman
0 siblings, 1 reply; 3+ messages in thread
From: Johannes Weiner @ 2009-02-17 19:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: Mel Gorman, linux-mm, linux-kernel
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 <hannes@cmpxchg.org>
Cc: Mel Gorman <mel@csn.ul.ie>
---
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;
--
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>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [patch] vmscan: respect higher order in zone_reclaim()
2009-02-17 19:48 [patch] vmscan: respect higher order in zone_reclaim() Johannes Weiner
@ 2009-02-18 10:12 ` Mel Gorman
2009-02-18 10:26 ` Johannes Weiner
0 siblings, 1 reply; 3+ messages in thread
From: Mel Gorman @ 2009-02-18 10:12 UTC (permalink / raw)
To: Johannes Weiner; +Cc: Andrew Morton, linux-mm, linux-kernel
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@csn.ul.ie>
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@cmpxchg.org>
> Cc: Mel Gorman <mel@csn.ul.ie>
> ---
> 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, 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>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [patch] vmscan: respect higher order in zone_reclaim()
2009-02-18 10:12 ` Mel Gorman
@ 2009-02-18 10:26 ` Johannes Weiner
0 siblings, 0 replies; 3+ messages in thread
From: Johannes Weiner @ 2009-02-18 10:26 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linux-mm, linux-kernel
On Wed, Feb 18, 2009 at 10:12:04AM +0000, Mel Gorman wrote:
> 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@csn.ul.ie>
>
> 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.
Agreed, this is better. Thank you, Mel.
--
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>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-02-18 10:23 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-17 19:48 [patch] vmscan: respect higher order in zone_reclaim() Johannes Weiner
2009-02-18 10:12 ` Mel Gorman
2009-02-18 10:26 ` Johannes Weiner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox