Commit a79311c14eae4bb946a97af25f3e1b17d625985d "vmscan: bail out ofdirect reclaim after swap_cluster_max pages" moved the nr_reclaimedcounter into the scan control to accumulate the number of allreclaimed pages in one direct reclaim invocation.

The commit missed to actually adjust do_try_to_free_pages() which nowdoes not initialize sc.nr_reclaimed and makes shrink_zone() makeassumptions on whether to bail out of the reclaim cycle based on anuninitialized value.

Fix it up by initializing the counter to zero before entering thepriority loop.

The comment of the .nr_reclaimed field says it accumulates the reclaimcounter over ONE shrink_zones() call. This means, we should break outif ONE shrink_zones() call alone does more than swap_cluster_max.

OTOH, the patch title suggests that we break out if ALL shrink_zones()calls in the priority loop have reclaimed that much. I.e.accumulating the reclaimed number over the prio loop, not just overone zones iteration.

From the patch description I couldn't really make sure what theintended behaviour was.

So, should the sc.nr_reclaimed be reset before the prio loop or ineach iteration of the prio loop?

Either this patch is wrong or the comment above .nr_reclaimed is.

And why didn't this have any observable effects? Do I miss somethingreally obvious here?