lkml.org 
[lkml]   [2021]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 3/8] mm/vmscan: Throttle reclaim when no progress is being made
From
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@techsingularity.net>
...
> @@ -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
>

\
 
 \ /
  Last update: 2021-10-14 14:32    [W:0.189 / U:6.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site