On Fri, Mar 4, 2022 at 10:40 AM Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > Daniel Dao has reported [1] a regression on workloads that may trigger > a lot of refaults (anon and file). The underlying issue is that flushing > rstat is expensive. Although rstat flush are batched with (nr_cpus * > MEMCG_BATCH) stat updates, it seems like there are workloads which > genuinely do stat updates larger than batch value within short amount of > time. Since the rstat flush can happen in the performance critical > codepaths like page faults, such workload can suffer greatly. > > This patch fixes this regression by making the rstat flushing > conditional in the performance critical codepaths. More specifically, > the kernel relies on the async periodic rstat flusher to flush the stats > and only if the periodic flusher is delayed by more than twice the > amount of its normal time window then the kernel allows rstat flushing > from the performance critical codepaths. > > Now the question: what are the side-effects of this change? The worst > that can happen is the refault codepath will see 4sec old lruvec stats > and may cause false (or missed) activations of the refaulted page which > may under-or-overestimate the workingset size. Though that is not very > concerning as the kernel can already miss or do false activations. > > There are two more codepaths whose flushing behavior is not changed by > this patch and we may need to come to them in future. One is the > writeback stats used by dirty throttling and second is the deactivation > heuristic in the reclaim. For now keeping an eye on them and if there is > report of regression due to these codepaths, we will reevaluate then. > > Link: https://lore.kernel.org/all/CA+wXwBSyO87ZX5PVwdHm-=dBjZYECGmfnydUicUyrQqndgX2MQ@xxxxxxxxxxxxxx [1] > Fixes: 1f828223b799 ("memcg: flush lruvec stats in the refault") > Signed-off-by: Shakeel Butt <shakeelb@xxxxxxxxxx> > Reported-by: Daniel Dao <dqminh@xxxxxxxxxxxxxx> > Cc: <stable@xxxxxxxxxxxxxxx> > --- See my testing results here: https://lore.kernel.org/linux-mm/CABWYdi2usrWOnOnmKYYvuFpE=yJmgtq4a7u6FiGJGJkskv+eVQ@xxxxxxxxxxxxxx/ Tested-by: Ivan Babrou <ivan@xxxxxxxxxxxxxx>
