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 63BE7C433EF for ; Mon, 28 Feb 2022 18:46:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E44218D0002; Mon, 28 Feb 2022 13:46:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF5F18D0001; Mon, 28 Feb 2022 13:46:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBC648D0002; Mon, 28 Feb 2022 13:46:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id BBA368D0001 for ; Mon, 28 Feb 2022 13:46:57 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6AC78181BD7A9 for ; Mon, 28 Feb 2022 18:46:57 +0000 (UTC) X-FDA: 79193070474.28.3B0AEBC Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf23.hostedemail.com (Postfix) with ESMTP id D3A39140008 for ; Mon, 28 Feb 2022 18:46:56 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 91D2E219A0; Mon, 28 Feb 2022 18:46:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1646074015; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XFD/luhJC8LruRYLMs0gTooM9kEU0Vb0THBd4sc3pRA=; b=KRyo6rUkMNul2GZJKG7Kx0l4Nw4gD3yieyj/lCJCTigs5UFZ978tEqO1/WbNe75Q6r5PU/ jEvk+0GNiPgx1SINVBkCHyUeG/o7df+NptnWhTTZ+74gBbV0gL7jhYSV9B5RCwwVVOAH9R vHSGjFMxoT/+7S52NU/YCFOvI+99ku4= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 6539F13AE1; Mon, 28 Feb 2022 18:46:55 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id rAuLF58YHWJGTgAAMHmgww (envelope-from ); Mon, 28 Feb 2022 18:46:55 +0000 Date: Mon, 28 Feb 2022 19:46:53 +0100 From: Michal =?iso-8859-1?Q?Koutn=FD?= To: Shakeel Butt Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Ivan Babrou , Cgroups , Linux MM , LKML , Daniel Dao , stable Subject: Re: [PATCH] memcg: async flush memcg stats from perf sensitive codepaths Message-ID: <20220228184653.GA1812@blackbody.suse.cz> References: <20220226002412.113819-1-shakeelb@google.com> <20220225165842.561d3a475310aeab86a2d653@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: D3A39140008 X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=KRyo6rUk; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf23.hostedemail.com: domain of mkoutny@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mkoutny@suse.com X-Stat-Signature: qadpntzks6eikn9xpi1kor745r7anbyt X-HE-Tag: 1646074016-261397 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, Feb 25, 2022 at 05:42:57PM -0800, Shakeel Butt wrote: > Yes, the right fix would be to optimize the flushing code (but that > would require more work/time). However I still think letting > performance critical code paths to skip the sync flush would be good > in general. So, if the current patch is not to your liking we can > remove mem_cgroup_flush_stats() from workingset_refault(). What about flushing just the subtree of the memcg where the refault happens? It doesn't reduce the overall work and there's still full-tree cgroup_rstat_lock but it should make the chunks of work smaller durations more regular. Michal