On 03/20/2013 12:18 PM, Michal Hocko wrote:
On Sun 17-03-13 13:04:07, Mel Gorman wrote: [...]diff --git a/mm/vmscan.c b/mm/vmscan.c index 88c5fed..4835a7a 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2593,6 +2593,32 @@ static bool prepare_kswapd_sleep(pg_data_t *pgdat, int order, long remaining, } /* + * kswapd shrinks the zone by the number of pages required to reach + * the high watermark. + */ +static void kswapd_shrink_zone(struct zone *zone, + struct scan_control *sc, + unsigned long lru_pages) +{ + unsigned long nr_slab; + struct reclaim_state *reclaim_state = current->reclaim_state; + struct shrink_control shrink = { + .gfp_mask = sc->gfp_mask, + }; + + /* Reclaim above the high watermark. */ + sc->nr_to_reclaim = max(SWAP_CLUSTER_MAX, high_wmark_pages(zone));OK, so the cap is at high watermark which sounds OK to me, although I would expect balance_gap being considered here. Is it not used intentionally or you just wanted to have a reasonable upper bound? I am not objecting to that it just hit my eyes.
This is the maximum number of pages to reclaim, not the point at which to stop reclaiming. I assume Mel chose this value because it guarantees that enough pages will have been freed, while also making sure that the value is scaled according to zone size (keeping pressure between zones roughly equal). -- All rights reversed -- 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>