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 79ACEC4332F for ; Thu, 9 Nov 2023 03:09:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D46BA8D00D0; Wed, 8 Nov 2023 22:09:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CD02C8D0073; Wed, 8 Nov 2023 22:09:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B702C8D00D0; Wed, 8 Nov 2023 22:09:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A22DF8D0073 for ; Wed, 8 Nov 2023 22:09:04 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 76C6EB5A72 for ; Thu, 9 Nov 2023 03:09:04 +0000 (UTC) X-FDA: 81436934208.09.5AE5241 Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by imf24.hostedemail.com (Postfix) with ESMTP id BFFF0180003 for ; Thu, 9 Nov 2023 03:09:02 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HPk3C0xb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699499342; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hm2K3rsZVkBARWD83CScKZj3mi6JLbGspKfGu8tGAo0=; b=8n2T6BI5ft9A4muACLNZvqhi5XZXKHgx22jUqEkaTRtjD991K16jyL2LK7RwwQb/hGRq7B kol7dat54UnQjr+Ug4H4U58kURV/oe9/SXKWJxg9hiz/ol701VDwHzed6a+Iv32btUusgh URCmBiz5KFx8Pw7tHW5/d8ylq/FI4EI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HPk3C0xb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699499342; a=rsa-sha256; cv=none; b=wsjHXUPUnuhgdZefDWS9jjUHmI2iRcUtbUufe3UEUMCHy+eqebLh3J9bsT4GMz+jR7thRT Qy0kfTeykQFw+xWyAT70WnDe6obf0wVG+LDhVk5K4PUGG1/+94Mdx7FYe9oD8FPMYxpRJp Dk/TN84B+VYKMAjW9P9SMQIZHuET/aU= Received: by mail-io1-f50.google.com with SMTP id ca18e2360f4ac-7a94a3b0a49so14731339f.2 for ; Wed, 08 Nov 2023 19:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699499342; x=1700104142; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hm2K3rsZVkBARWD83CScKZj3mi6JLbGspKfGu8tGAo0=; b=HPk3C0xb5pcfv/9PF2vCWXyA8ZMsRlVkWcmUQKsrnyPSKCli1UPjMfqUEMHTAqtdgZ ReiDDSd5F2kEfYznChu72KtsYNpw6lW566zBS5TXx4akIT8IWcd0cGtJgNlmv9414Rkc ELwl8aobfXPJoRqUtAZ6yMu3JkascSbfd80VjNKiqojwBoG6KaZnK8aqdCL+zt57PsjY v6+1EE2RvRDjHnhUvaXBV0OzJfDVKB3I5+DIgh3knxFTjQg/wXdifbNVdVhK/ZOmsYco 3mWlsNDDNyw8zt6nKOLuW3c2kzwezEK/QhWvvaoEHhw5b2e+2ocplRqMNCkH2TFq8cKA KUTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699499342; x=1700104142; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hm2K3rsZVkBARWD83CScKZj3mi6JLbGspKfGu8tGAo0=; b=U/XEsVcxLVToCo22o1Yt0A9h3Z8e03yJdEWjgmZJaU6ALYSF6mnhy1IEvQuMX/R+Wg zvZpziIlZXhIxN05qlce59UVZ8jRbKVtwATKLGv3UpIZ6IBfZf0spJw3lbkgglL8O7kf mEKN6RBqyaYlFsD6qANR+ip/jJb1Oc4Cvlb3ynhkqkwCE1JdsKyp0lFt38gAV3y8EF++ hGyym3tauAx1loQ7hBLQZo8bRst8ZC8o/X+O12mSOIuoQljC6cECEUmKPE4JVugQgGuy mTZ2Kf9wfZl73rbROdChgxs3dp7t9MgQPB8Ob1YWFVXZqHLdm5fF2qj2MS8UMWWzS00m ng4g== X-Gm-Message-State: AOJu0YynjriMmZufHAwHxj2t+8RTIulmIterQdTGG3bWsn/Bo2zAmghk G30LyRHxVecPDy7vqJf+9N4VMf4Dn5Y/gwvFzxs= X-Google-Smtp-Source: AGHT+IEs1xKUjGfuAvj54SEziWA66fE65fl1xhY3ldsYrxOi51MgEw2rd2WrRqrWEH1WysLGgBl6ej9/UZ+7M9AxJ6o= X-Received: by 2002:a6b:5915:0:b0:7a9:b1c9:665a with SMTP id n21-20020a6b5915000000b007a9b1c9665amr522951iob.6.1699499341812; Wed, 08 Nov 2023 19:09:01 -0800 (PST) MIME-Version: 1.0 References: <20231102234236.1784543-1-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Wed, 8 Nov 2023 19:08:50 -0800 Message-ID: Subject: Re: [RFC PATCH v3] zswap: memcontrol: implement zswap writeback disabling To: Chris Li Cc: Yosry Ahmed , akpm@linux-foundation.org, tj@kernel.org, lizefan.x@bytedance.com, hannes@cmpxchg.org, cerasuolodomenico@gmail.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, mhocko@kernel.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, hughd@google.com, corbet@lwn.net, konrad.wilk@oracle.com, senozhatsky@chromium.org, rppt@kernel.org, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, david@ixit.cz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: BFFF0180003 X-Stat-Signature: f8thb9nkejg7687ezj893any9osga6bb X-HE-Tag: 1699499342-849951 X-HE-Meta: U2FsdGVkX1/NWCeqwKZbUJsEp2Yg8ClkgEHhYxsZdQUCHbhRCVnv7dJGugTaRA/6s+1h6TPYLEPHI6O2Zxw2uemq0lyKvcD6j89dAfIae1el2AHPFC96PNFf6iorro4/bKoHSG5VttsgbrJDiVUlrNO6G/n80v9guKdaJGt8Jqishwfo3gd72y1nCNyGeaTxY1U3m+IJ1Zogu0x47dWxo5ur6XGXWcqKcaxdR9FlPRfr1XMhmgon7B+MvSZEEovD4rIfTbTEW53xFEaZ1Eu//weUrc1H1wBxW+JdBN43Bo+n1yp4jLBWcvtjeLAS4OGOlqvkmdFRy/Fr44Xn1lkK0iR7YZKILTAQKXL0ssXM44/FgdgiUm4FEsGUJ9csd4D8B/5YFsTgmahtq+uryQRl3hlytcCk9y4U6h3oU+imTjhdZ8a5BUD5cdElEoRzHxc4sIhDlvoUc6CEfEVlJiljTsE60EAWb0fd9gU/0g82kPWH7g4m7xuZkNmsMiqAy+qAWjYUmlpkvjNCn6fZe2tHslA5Foo+dnnVzrBDN5W7/SJXA8StbRrIMuTqrzFKj3EmLkzmkvj8kRoRhVxNXr9VDfrE2+r+L+8a4P8BoFVYeJUx4n+N4hM+Ce5F6uE1zaXo2dAGVTUrTJkWNs7cwWfHIrTwZpee2RRNiy2Dm/QdlF154mKKpVBXtt4RpLx7089S7kC5M8P791Q15Nuec8o5KZARfc91KPJ4nya4gAMCqkXVjROeNptb1vHF4/UUaVBthZVzV8RO+HvHwzi9kzhlSRdWE0jRhHwQ3R75rsXBo/D0i+E8PFw4KfM8NqIGmiTSA/Zlvfq7eFaYoEW40IJXh1DnBI9WbvzUS+j2D/F8haJCPwHDhAuWkxvD77dUgfQ/VfXClCLjXiHxyaCnBc5BPV6ehyA6/CFmr7k9ndEx92FqWzj3NZg4o971Zl1eWCKmoHXSqSp010mpai77KKX rUs1yqrr 6zScqF8/BJhr/4p1nptTJ0DQHfF7/wbPqtkm6busNQWQ/cpOClZsq8VRjaG8yXCWSW3VbWN3G6nMvJRrdbEsZkFrO+lOzLB+EBgP0gOxop10YdLc3EsDnyXePOvF8zHa7iFeXieC5DjcXgz/YNRKJ0ScEomIdpD6Bn9XJSezpR8TrJ3TknWqu5/HZiSxELapZt8wAk7MaG/03j41lqoiF/d+wauHIFzY4jHiJbUfTUDPduik4sNta1a7s2UGdoJWM/sSZcJYdJ5Ec0HljlbN1zXN6emt2f+2bK91oFEgnMWhZgh6gXRC7lEmhJToHcJx/hOSk1Bzl5J7yASEFebUZnBXzKM4OdEOa3ZsZcjVAK91QjfAmaf/ynN3luPJmIX/77j8QHWqBPgftvgHegm/tRSM2I0rOhCZUFzgPghRL4o+ApOUIOoW7OEcnbA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000305, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Nov 8, 2023 at 6:41=E2=80=AFPM Chris Li wrote: > > Hi Nhant, > > On Fri, Nov 3, 2023 at 12:24=E2=80=AFPM Nhat Pham wro= te: > > > > > > Would it be more convenient if the initial value is inherited from th= e > > > parent (the root starts with true)? > > > > > > I can see this being useful if we want to set it to false on the > > > entire machine or one a parent cgroup, we can set it before creating > > > any children instead of setting it to 0 every time we create a new > > > cgroup. > > > > I'm not 100% sure about the benefit or have a strong opinion one way > > or another, but this sounds like a nice-to-have detail to me, and a rel= atively > > low cost one (both in effort and at runtime) at that too. > > > > Propagating the change everytime we modify the memory.zswap.writeback > > value of the ancestor might be data race-prone (and costly, depending o= n > > how big the cgroup subtree is), but this is just a one-time-per-cgroup > > propagation (at the new cgroup creation time). > > I think Yosary was suggesting inheriting the initial value from > parents. That is just one level look up when you create the new > cgroup, using the parent value as default. No recursive. > What you described above seems different to me. I understand what you > are suggesting is that writing to the parent cgroup will recursively > write to all child cgroup. > > > > Can anyone come up with a failure case for this change, or why it might= be > > a bad idea? > > I would suggest against recursive changing value behavior. > What if you want the parent but also want the child to keep its value > not changed? Every change to the parent will have to go through the > child to flip it back. > Inherit from the parent seems fine. > > Chris Hi Chris, I've actually sent out a new version of the patch series implementing (what I believed to be) Yosry's suggestion. Feel free to take a look! https://lore.kernel.org/all/20231106231158.380730-1-nphamcs@gmail.com/ Here, I was actually agreeing with you - recursive propagation would not be a good idea. Best, Nhat