Re: Free memory never fully used, swapping

From: KOSAKI Motohiro
Date: Thu Nov 25 2010 - 21:31:50 EST


> record the order seems not sufficient. in balance_pgdat(), the for look
> exit only when:
> priority <0 or sc.nr_reclaimed >= SWAP_CLUSTER_MAX.
> but we do if (sc.nr_reclaimed < SWAP_CLUSTER_MAX)
> order = sc.order = 0;
> this means before we set order to 0, we already reclaimed a lot of
> pages, so I thought we need set order to 0 earlier before there are
> enough free pages. below is a debug patch.
>
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index d31d7ce..ee5d2ed 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2117,6 +2117,26 @@ unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *mem_cont,
> }
> #endif
>
> +static int all_zone_enough_free_pages(pg_data_t *pgdat)
> +{
> + int i;
> +
> + for (i = 0; i < pgdat->nr_zones; i++) {
> + struct zone *zone = pgdat->node_zones + i;
> +
> + if (!populated_zone(zone))
> + continue;
> +
> + if (zone->all_unreclaimable)
> + continue;
> +
> + if (!zone_watermark_ok(zone, 0, high_wmark_pages(zone) * 8,
> + 0, 0))
> + return 0;
> + }
> + return 1;
> +}
> +
> /* is kswapd sleeping prematurely? */
> static int sleeping_prematurely(pg_data_t *pgdat, int order, long remaining)
> {
> @@ -2355,7 +2375,8 @@ out:
> * back to sleep. High-order users can still perform direct
> * reclaim if they wish.
> */
> - if (sc.nr_reclaimed < SWAP_CLUSTER_MAX)
> + if (sc.nr_reclaimed < SWAP_CLUSTER_MAX ||
> + (order > 0 && all_zone_enough_free_pages(pgdat)))
> order = sc.order = 0;

Ummm. this doesn't work. this place is processed every 32 pages reclaimed.
(see below code and comment). Theresore your patch break high order reclaim
logic.


/*
* We do this so kswapd doesn't build up large priorities for
* example when it is freeing in parallel with allocators. It
* matches the direct reclaim path behaviour in terms of impact
* on zone->*_priority.
*/
if (sc.nr_reclaimed >= SWAP_CLUSTER_MAX)
break;


--
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/