On Wed, 8 Dec 2010 16:16:59 +0100
Johannes Weiner <hannes@xxxxxxxxxxx> wrote:
> Kswapd tries to rebalance zones persistently until their high
> watermarks are restored.
>
> If the amount of unreclaimable pages in a zone makes this impossible
> for reclaim, though, kswapd will end up in a busy loop without a
> chance of reaching its goal.
>
> This behaviour was observed on a virtual machine with a tiny
> Normal-zone that filled up with unreclaimable slab objects.
Doesn't this mean that vmscan is incorrectly handling its
zone->all_unreclaimable logic?
> This patch makes kswapd skip rebalancing on such 'hopeless' zones and
> leaves them to direct reclaim.
>
> ...
>
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2191,6 +2191,25 @@ unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *mem_cont,
> }
> #endif
>
> +static bool zone_needs_scan(struct zone *zone, int order,
> + unsigned long goal, int classzone_idx)
> +{
> + unsigned long free, prospect;
> +
> + free = zone_page_state(zone, NR_FREE_PAGES);
> + if (zone->percpu_drift_mark && free < zone->percpu_drift_mark)
> + free = zone_page_state_snapshot(zone, NR_FREE_PAGES);
> +
> + if (__zone_watermark_ok(zone, order, goal, classzone_idx, 0, free))
> + return false;
> + /*
> + * Ensure that the watermark is at all restorable through
> + * reclaim. Otherwise, leave the zone to direct reclaim.
> + */
> + prospect = free + zone_reclaimable_pages(zone);
> + return prospect >= goal;
> +}
presumably in certain cases that's a bit more efficient than doing the
scan and using ->all_unreclaimable. But the scanner shouldn't have got
stuck! That's a regresion which got added, and I don't think that new
code of this nature was needed to fix that regression.
Did this zone end up with ->all_unreclaimable set? If so, why was
kswapd stuck in a loop scanning an all-unreclaimable zone?
Also, if I'm understanding the new logic then if the "goal" is 100
pages and zone_reclaimable_pages() says "50 pages potentially
reclaimable" then kswapd won't reclaim *any* pages. If so, is that
good behaviour? Should we instead attempt to reclaim some of those 50
pages and then give up? That sounds like a better strategy if we want
to keep (say) network Rx happening in a tight memory situation.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>