[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZHnKOVfwHQXBwA4k@dhcp22.suse.cz>
Date: Fri, 2 Jun 2023 12:53:45 +0200
From: Michal Hocko <mhocko@...e.com>
To: Marcelo Tosatti <mtosatti@...hat.com>
Cc: Christoph Lameter <cl@...ux.com>,
Aaron Tomlin <atomlin@...mlin.com>,
Frederic Weisbecker <frederic@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH 1/4] vmstat: allow_direct_reclaim should use
zone_page_state_snapshot
Andrew, as I've stated in previously, this sounds like a reasonable
standalone fix worth taking independently of the rest.
On Tue 30-05-23 11:52:35, Marcelo Tosatti wrote:
> A customer provided evidence indicating that a process
> was stalled in direct reclaim:
>
> - The process was trapped in throttle_direct_reclaim().
> The function wait_event_killable() was called to wait condition
> allow_direct_reclaim(pgdat) for current node to be true.
> The allow_direct_reclaim(pgdat) examined the number of free pages
> on the node by zone_page_state() which just returns value in
> zone->vm_stat[NR_FREE_PAGES].
>
> - On node #1, zone->vm_stat[NR_FREE_PAGES] was 0.
> However, the freelist on this node was not empty.
>
> - This inconsistent of vmstat value was caused by percpu vmstat on
> nohz_full cpus. Every increment/decrement of vmstat is performed
> on percpu vmstat counter at first, then pooled diffs are cumulated
> to the zone's vmstat counter in timely manner. However, on nohz_full
> cpus (in case of this customer's system, 48 of 52 cpus) these pooled
> diffs were not cumulated once the cpu had no event on it so that
> the cpu started sleeping infinitely.
> I checked percpu vmstat and found there were total 69 counts not
> cumulated to the zone's vmstat counter yet.
>
> - In this situation, kswapd did not help the trapped process.
> In pgdat_balanced(), zone_wakermark_ok_safe() examined the number
> of free pages on the node by zone_page_state_snapshot() which
> checks pending counts on percpu vmstat.
> Therefore kswapd could know there were 69 free pages correctly.
> Since zone->_watermark = {8, 20, 32}, kswapd did not work because
> 69 was greater than 32 as high watermark.
>
> Change allow_direct_reclaim to use zone_page_state_snapshot, which
> allows a more precise version of the vmstat counters to be used.
>
> allow_direct_reclaim will only be called from try_to_free_pages,
> which is not a hot path.
>
> Testing: Due to difficulties accessing the system, it has not been
> possible for the reproducer to test the patch (however its
> clear from available data and analysis that it should fix it).
>
> Reviewed-by: Michal Hocko <mhocko@...e.com>
> Reviewed-by: Aaron Tomlin <atomlin@...mlin.com>
> Signed-off-by: Marcelo Tosatti <mtosatti@...hat.com>
>
> ---
>
> Index: linux-vmstat-remote/mm/vmscan.c
> ===================================================================
> --- linux-vmstat-remote.orig/mm/vmscan.c
> +++ linux-vmstat-remote/mm/vmscan.c
> @@ -6887,7 +6887,7 @@ static bool allow_direct_reclaim(pg_data
> continue;
>
> pfmemalloc_reserve += min_wmark_pages(zone);
> - free_pages += zone_page_state(zone, NR_FREE_PAGES);
> + free_pages += zone_page_state_snapshot(zone, NR_FREE_PAGES);
> }
>
> /* If there are no reserves (unexpected config) then do not throttle */
>
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists