On Tue, Mar 28, 2023 at 12:02 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > On Tue, Mar 28, 2023 at 8:19 AM Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > > > On Mon, Mar 27, 2023 at 11:16 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > > > Memory reclaim is a sleepable context. Allow sleeping when flushing > > > memcg stats to avoid unnecessarily performing a lot of work without > > > sleeping. This can slow down reclaim code if flushing stats is taking > > > too long, but there is already multiple cond_resched()'s in reclaim > > > code. > > > > > > Signed-off-by: Yosry Ahmed <yosryahmed@xxxxxxxxxx> > > > > Acked-by: Shakeel Butt <shakeelb@xxxxxxxxxx> > > > > > --- > > > mm/vmscan.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > > index a9511ccb936f..9c1c5e8b24b8 100644 > > > --- a/mm/vmscan.c > > > +++ b/mm/vmscan.c > > > @@ -2845,7 +2845,7 @@ static void prepare_scan_count(pg_data_t *pgdat, struct scan_control *sc) > > > * Flush the memory cgroup stats, so that we read accurate per-memcg > > > * lruvec stats for heuristics. > > > */ > > > - mem_cgroup_flush_stats_atomic(); > > > + mem_cgroup_flush_stats(); > > > > I wonder if we should just replace this with > > mem_cgroup_flush_stats_ratelimited(). > > Thanks for taking a look! > > I was hesitant about doing this because the flush call is inside the > retry loop, and it seems like we want to get fresh stats on each > retry. It seems very likely that we end up not flushing between > retries with mem_cgroup_flush_stats_ratelimited(). > > Maybe change it if we observe problems with non-atomic flushing? Yeah, let's leave it for the future if we see the issue.
