Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3697285pxb; Wed, 13 Oct 2021 11:03:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwNGVLvWN3zwbp7eNl9w4hhI5rnjSXfp75AKWz8xh6RaWQTMEqRsgmXIP39Frq5tFHEohNu X-Received: by 2002:a17:902:b205:b0:13d:b0a1:da90 with SMTP id t5-20020a170902b20500b0013db0a1da90mr689591plr.26.1634148183014; Wed, 13 Oct 2021 11:03:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634148183; cv=none; d=google.com; s=arc-20160816; b=ADCMCZMm5PL3ZMbRJKe5CImKsuNs8odxIGmhSr6Yya5OtreM+DmO6v+4Yr9Ya1IPwR HJezU451eZum7wFY8Havv6engl+F698/Z24mcG6iqSgCSXhSgc2ix0qKZT+yurSQ9SmQ 1v6RzNccD+T9ie1yKw/xGxiUNbSOLC+9s5NNYkDFQN7MJetGprxs1bMV64FIGb3cepFS UfX6CtYz39jGTwFXI22+chN0BjHsYIFwvQ+Se8/cdaNK8WqW3uCiIPV+mShqOBgwnUM9 vdFVD3/ffF/YtB2QiicicNMSWFu1OyM4fUz5CM4eETEMNVM43F8y0QOAivrF50ymgk3m KNyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=5NE66Dj/QGO/V+dUIB7Cr5kb37zCYA6r5tio5RjzNII=; b=MwhT3Pm7qPcixup3+Bu8MIQSPO5CbC+BYyWkmJILQfuHRq6jtUW8VMK4xqHcd4gxLK PLdWs62c78iohJZZSHBpaNKQOMeKtAXg65R1xsGhhXWLuiZCffINv8zxnOjtRDyqlzI1 nel4N+FSjkRpjIwTfDdvycEJ1a4nB9d458XtgZm9wXI53aPv995FQPWMq2MRsl44MuPr d5cgvVnenVnnZQ+VamJtyrtetWSpCQPWF+vv91XGkUG40TaZjFb7jP23vh5L+Zc3OqMP uGAto7sgPwaj/fjnYyyZzbNtQJzHNEEHFJV2qSPAOZGmoKOEpOHqIvVqFAeWkXYsxHB8 cEHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b="B5V05/9o"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m2si274195pgb.254.2021.10.13.11.02.49; Wed, 13 Oct 2021 11:03:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b="B5V05/9o"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231268AbhJMSD3 (ORCPT + 99 others); Wed, 13 Oct 2021 14:03:29 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:46258 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229814AbhJMSD2 (ORCPT ); Wed, 13 Oct 2021 14:03:28 -0400 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 9520E219C7; Wed, 13 Oct 2021 18:01:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1634148083; 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=5NE66Dj/QGO/V+dUIB7Cr5kb37zCYA6r5tio5RjzNII=; b=B5V05/9o7Qyc+X/mDJCKHrJHU6FQg67zI22a1OGNF5iATFfW4V+ZU+C3WOUGmUajfs4qXT b99ySrjT5mzdxKSCuG0VXQ051wZ81Y+pAXYTdRsnw0QOlXMlLv1cVG9822BZobjv//KMc6 y/fzTXdhw/CXtYD2grraAEdVjDxI85s= 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 7BE8813D10; Wed, 13 Oct 2021 18:01:23 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id PX2IHfMeZ2G2PQAAMHmgww (envelope-from ); Wed, 13 Oct 2021 18:01:23 +0000 Date: Wed, 13 Oct 2021 20:01:22 +0200 From: Michal =?iso-8859-1?Q?Koutn=FD?= To: Shakeel Butt Cc: Johannes Weiner , Michal Hocko , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] memcg: unify memcg stat flushing Message-ID: <20211013180122.GA1007@blackbody.suse.cz> References: <20211001190040.48086-1-shakeelb@google.com> <20211001190040.48086-2-shakeelb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211001190040.48086-2-shakeelb@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Shakeel. (Sorry for taking so long getting down to this.) On Fri, Oct 01, 2021 at 12:00:40PM -0700, Shakeel Butt wrote: > There is no need for that. We just need one flusher and everyone else > can benefit. I imagine a cgroup with an intricate deep hiearchy with many updates and a separate (simpler) sibling/independent cgroup that would need to pay the costs of the first hierarchy updates [1] when it asks just for its own stats (bound by the amount that's leftover from the periodic updates). The stats files (or wb stats) are likely not that time sensitive and the reclaim (that can be local only but is slow path anyway) already uses the global flushing. I wonder whether the bigger benefit would be to retain the global stats_flush_threshold counter but flush only local subtree. Thanks, Michal [1] At first I thought non-memcg updates would interfere too via rstat tree but I see it's actually filtered with the stats_flush_threshold so only foreign memcg updates are relevant.