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 815EBC433EF for ; Tue, 17 May 2022 23:52:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04D0A6B0072; Tue, 17 May 2022 19:52:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3F476B0073; Tue, 17 May 2022 19:52:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2E0A6B0074; Tue, 17 May 2022 19:52:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D3E676B0072 for ; Tue, 17 May 2022 19:52:19 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id AA7D230BA5 for ; Tue, 17 May 2022 23:52:19 +0000 (UTC) X-FDA: 79476886398.12.3F1BF33 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id 43CB240031 for ; Tue, 17 May 2022 23:52:06 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 1328E614C3; Tue, 17 May 2022 23:52:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D4B0C34117; Tue, 17 May 2022 23:52:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1652831537; bh=pEz6dre40UCCubkWjCpmYmIXIWT0QJP+YHG6iJ3oqAE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tsprR4zmK/oALRYBT6vfLxQ1klcvHAWxPcTURMr4US/hz7Uw0voe1Rd7mrChl8sdH 2miTXW+EY7qU+TEI2unOpAlcbme0xr2QXB48zpwSoZaqLZ+c/nu+dY2yTH5iNx0vo8 yhD8XhZUkOY2U6dkpIa/o/EV1/RwxLY79S8QzLW0= Date: Tue, 17 May 2022 16:52:16 -0700 From: Andrew Morton To: Johannes Weiner Cc: Michal =?ISO-8859-1?Q?Koutn=FD?= , Michal Hocko , Roman Gushchin , Shakeel Butt , Seth Jennings , Dan Streetman , Minchan Kim , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 6/6] zswap: memcg accounting Message-Id: <20220517165216.7acd8434f8b25606836e21e6@linux-foundation.org> In-Reply-To: References: <20220510152847.230957-1-hannes@cmpxchg.org> <20220510152847.230957-7-hannes@cmpxchg.org> <20220511173218.GB31592@blackbody.suse.cz> <20220513151426.GC16096@blackbody.suse.cz> <20220516143459.GA17557@blackbody.suse.cz> 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-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 43CB240031 X-Stat-Signature: nrgu7c3fisd4jpehxn4mxqxscbqf5w3s Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=tsprR4zm; spf=pass (imf04.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1652831526-363128 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 Mon, 16 May 2022 16:01:05 -0400 Johannes Weiner wrote: > > > Flushing unnecessary groups with a ratelimit doesn't sound like an > > > improvement to me. > > > > Then I'm only concerned about a situation when there's a single deep > > memcg that undergoes both workingset_refault() and zswap querying. > > The latter (bare call to cgroup_rstat_flush()) won't reset > > stats_flush_threshold, so the former (or the async flush more likely) > > would attempt a flush too. The flush work (on the leaf memcg) would be > > done twice even though it may be within the tolerance of cumulated > > error the second time. > > > > This is a thing that might require attention in the future (depending on > > some data how it actually performs). I see how the current approach is > > justified. > > Yes, we can optimize it should the need arise. So far it's been fine. > > Thanks for your thoughts, Michal. Me too. I think everything is settled here so I plan to import this series into mm-stable in a couple of days. at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/ documentation-filesystems-proc-update-meminfo-section.patch documentation-filesystems-proc-update-meminfo-section-fix.patch documentation-filesystems-proc-update-meminfo-section-fix-2.patch mm-kconfig-move-swap-and-slab-config-options-to-the-mm-section.patch mm-kconfig-group-swap-slab-hotplug-and-thp-options-into-submenus.patch mm-kconfig-group-swap-slab-hotplug-and-thp-options-into-submenus-fix.patch mm-kconfig-group-swap-slab-hotplug-and-thp-options-into-submenus-fix-fix.patch mm-kconfig-simplify-zswap-configuration.patch mm-zswap-add-basic-meminfo-and-vmstat-coverage.patch zswap-memcg-accounting.patch zswap-memcg-accounting-fix.patch zswap-memcg-accounting-fix-2.patch