From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8BBBC433EF for ; Mon, 7 Mar 2022 02:44:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 566DA8D0003; Sun, 6 Mar 2022 21:44:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4EF978D0001; Sun, 6 Mar 2022 21:44:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 369D48D0003; Sun, 6 Mar 2022 21:44:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190]) by kanga.kvack.org (Postfix) with ESMTP id 263EE8D0001 for ; Sun, 6 Mar 2022 21:44:09 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id CF9F5A15F4 for ; Mon, 7 Mar 2022 02:44:08 +0000 (UTC) X-FDA: 79216045776.30.C160AF0 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf02.hostedemail.com (Postfix) with ESMTP id 347468000D for ; Mon, 7 Mar 2022 02:44:08 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C5156B80EDE; Mon, 7 Mar 2022 02:44:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DCF9C340EC; Mon, 7 Mar 2022 02:44:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1646621045; bh=fXrrtpJvgRp7AsWlaFX0EIrBU3vOypZe0/w7Wy6tFaw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Yl3BC2AszB49zMZHwLObBmVoM7K4Jl5NAwLN0LcontcU6+PloRGpwxKbmoFAmASQj nil01KZFN6gYYCX2zEhBcI6kMloe1CybbviLAQBKoOkg5XN9rEbtCJknWmiocyWi5A D0VbwX/8Vvx4sLUsNXs5QUX9ruW6Do6QDnUJL25c= Date: Sun, 6 Mar 2022 18:44:04 -0800 From: Andrew Morton To: Shakeel Butt Cc: =?ISO-8859-1?Q?"Michal_Koutn=FD"?= , Johannes Weiner , Michal Hocko , Roman Gushchin , Ivan Babrou , Frank Hofmann , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Daniel Dao , stable@vger.kernel.org Subject: Re: [PATCH] memcg: sync flush only if periodic flush is delayed Message-Id: <20220306184404.049447f8447d288fde34cabe@linux-foundation.org> In-Reply-To: <20220304184040.1304781-1-shakeelb@google.com> References: <20220304184040.1304781-1-shakeelb@google.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 347468000D X-Stat-Signature: 1jnmrxreswcoqjjtk6rgrp6a6axmf98e Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=Yl3BC2As; spf=pass (imf02.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspam-User: X-HE-Tag: 1646621048-431119 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 4 Mar 2022 18:40:40 +0000 Shakeel Butt 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. > > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > > ... > > @@ -648,10 +652,16 @@ void mem_cgroup_flush_stats(void) > __mem_cgroup_flush_stats(); > } > > +void mem_cgroup_flush_stats_delayed(void) > +{ > + if (rstat_flush_time && time_after64(jiffies_64, flush_next_time)) rstat_flush_time isn't defined for me and my googling indicates this is the first time the symbol has been used in the history of the world. I'm stumped. > + mem_cgroup_flush_stats(); > +} > + > > ... >