On 10/8/21 15:53, Mel Gorman wrote: > Memcg reclaim throttles on congestion if no reclaim progress is made. > This makes little sense, it might be due to writeback or a host of > other factors. > > For !memcg reclaim, it's messy. Direct reclaim primarily is throttled > in the page allocator if it is failing to make progress. Kswapd > throttles if too many pages are under writeback and marked for > immediate reclaim. > > This patch explicitly throttles if reclaim is failing to make progress. > > Signed-off-by: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> ... > @@ -3769,6 +3797,16 @@ unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *memcg, > trace_mm_vmscan_memcg_reclaim_end(nr_reclaimed); > set_task_reclaim_state(current, NULL); > > + if (!nr_reclaimed) { > + struct zoneref *z; > + pg_data_t *pgdat; > + > + z = first_zones_zonelist(zonelist, sc.reclaim_idx, sc.nodemask); > + pgdat = zonelist_zone(z)->zone_pgdat; > + > + reclaim_throttle(pgdat, VMSCAN_THROTTLE_NOPROGRESS, HZ/10); > + } Is this necessary? AFAICS here we just returned from: do_try_to_free_pages() shrink_zones() for_each_zone()... consider_reclaim_throttle() Which already throttles when needed and using the appropriate pgdat, while here we have to somewhat awkwardly assume the preferred one. > + > return nr_reclaimed; > } > #endif >