Re: [PATCH v2 2/2] memcg: periodically flush the memcg stats

From: Johannes Weiner <hannes@cmpxchg.org>
To: Shakeel Butt <shakeelb@google.com>
Cc: "Tejun Heo" <tj@kernel.org>,
	"Muchun Song" <songmuchun@bytedance.com>,
	"Michal Hocko" <mhocko@kernel.org>,
	"Roman Gushchin" <guro@fb.com>,
	"Michal Koutný" <mkoutny@suse.com>,
	"Huang Ying" <ying.huang@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] memcg: periodically flush the memcg stats
Date: Tue, 15 Jun 2021 15:29:55 -0400	[thread overview]
Message-ID: <YMj/s26uF+cQOB2D@cmpxchg.org> (raw)
In-Reply-To: <20210615174435.4174364-2-shakeelb@google.com>

Hey Shakeel,

On Tue, Jun 15, 2021 at 10:44:35AM -0700, Shakeel Butt wrote:
> At the moment memcg stats are read in four contexts:
> 
> 1. memcg stat user interfaces
> 2. dirty throttling
> 3. page fault
> 4. memory reclaim
> 
> Currently the kernel flushes the stats for first two cases. Flushing the
> stats for remaining two casese may have performance impact. Always
> flushing the memcg stats on the page fault code path may negatively
> impacts the performance of the applications. In addition flushing in the
> memory reclaim code path, though treated as slowpath, can become the
> source of contention for the global lock taken for stat flushing because
> when system or memcg is under memory pressure, many tasks may enter the
> reclaim path.
> 
> Instead of synchronously flushing the stats, this patch adds support of
> asynchronous periodic flushing of the memcg stats. For now the flushing
> period is hardcoded to 2*HZ but that can be changed later through maybe
> sysctl if need arise.

I'm concerned that quite a lot can happen in terms of reclaim and page
faults in 2 seconds. It's conceivable that the error of a fixed 2s
flush can actually exceed the error of a fixed percpu batch size.

The way the global vmstat implementation manages error is doing both:
ratelimiting and timelimiting. It uses percpu batching to limit the
error when it gets busy, and periodic flushing to limit the length of
time consumers of those stats could be stuck trying to reach a state
that the batching would otherwise prevent from being reflected.

Maybe we can use a combination of ratelimiting and timelimiting too?

We shouldn't flush on every fault, but what about a percpu ratelimit
that would at least bound the error to NR_CPU instead of nr_cgroups?

For thundering herds during reclaim: as long as they all tried to
flush from the root, only one of them would actually need to do the
work, and we could use trylock. If the lock is already taken, you can
move on knowing that somebody is already doing the shared flush work.