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 BC7E3C3DA4A for ; Wed, 14 Aug 2024 19:52:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3CE546B0088; Wed, 14 Aug 2024 15:52:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 32FD56B0089; Wed, 14 Aug 2024 15:52:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A9A86B008A; Wed, 14 Aug 2024 15:52:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EC25F6B0088 for ; Wed, 14 Aug 2024 15:52:22 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A6D518113D for ; Wed, 14 Aug 2024 19:52:22 +0000 (UTC) X-FDA: 82451897724.25.CBC391F Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) by imf23.hostedemail.com (Postfix) with ESMTP id E3FF2140003 for ; Wed, 14 Aug 2024 19:52:19 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XaHaf9hw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf23.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.217.54 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=1723665059; 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=IeoPsrjRFuK/BstJVImPOaM8kWcJho5fxj+w3CFGxj8=; b=TFHHi0RAo1ufIh7cjTLkVYyfcmuYQP1qgRl4Km2uZucm1/cDoiPXCUAJkqbJjsyKU6cyEZ XGLFt09c9VgKX/+vXfXF7Zh0aY1fb5TXfpaeYbbLfmTlU7qTtHcMb2UpSgtWNMj9wkixti d8jU1RHzh2Bv1wshjQLAB0xEA61YlGs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723665059; a=rsa-sha256; cv=none; b=3pOMSHbZP+rzwUAg/WJY2g5RNWR7kuElEhm2RD4+uAplCAgB6QwyLQUZ3q3Mp4vg/1L6LG oAxMsO0eR1HPqs8+l83cxdLNI0OHyjSLFG9dlO3OrUfy8jdI3gXfLEFbec8op8NmrTXX50 oVdb2Q//K/4CdIMrDlxYcPlbbGVkr/M= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XaHaf9hw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf23.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.217.54 as permitted sender) smtp.mailfrom=nphamcs@gmail.com Received: by mail-vs1-f54.google.com with SMTP id ada2fe7eead31-4928e347ac5so87190137.3 for ; Wed, 14 Aug 2024 12:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723665139; x=1724269939; 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=IeoPsrjRFuK/BstJVImPOaM8kWcJho5fxj+w3CFGxj8=; b=XaHaf9hw9igteb/ENJK0scc7/wAQBtKqNWbLLOTEhms/w+Zam/X1ZJ3cQlkJfETjyU ur/8RmyjxSbe82T0h5/Zcvk/SBcIkj84dkbRcgtljTF2GK5mHZCgHE3Ax9BEBd4olD2Q BBiCeHYW3DLeb1RZs9yu66ST2E5NI7lcuCnOZYHGejhJnXmg2rtoyApKi59TGcLtfjaC doKjj2XLsO4qnSvDeEQF5Y25aHauCafKZShk3jiYnR0EGMcH3d15NbJDvFjVTIJ6i8QG PCdlMEemYIE7wGRNlBs9xVNXfh2t0IfkjzP8IT2+NsYApNtmOqIpHPP/pthVTufyezkD 5fMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723665139; x=1724269939; 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=IeoPsrjRFuK/BstJVImPOaM8kWcJho5fxj+w3CFGxj8=; b=oc85L/GqkGDvmUTJEA/S+WaKm/jgI5AutpoCzdBEctPxoC7X2CO4vZ6TgvjMuMaKYv qxfFqOVVxLk81uyIiRlOWMIkp/hbg8ocgk6wQ/CI7zyGz0DJzv8UlgYYV7WkTr+D6C6x E4c8b65zIp3hz9D4ybMNoPBq/RNNLo9NmykUC97bVW/BwAPH8U5cXnHK6q8GjYea3v+w dP5vzJAXvwjFyOqJoL5RKuU72QAFQTBEtD1OZnkdqJwhQa4twr6jXp1kTpxe5W3hTu8m p6D2AJLYez5LCe8hn71SKRgZbbL2hWgtP3BB/0OByALVDV75fgo2EfAO9x96M6OsSBQ+ a8aQ== X-Forwarded-Encrypted: i=1; AJvYcCV4yhwCDLV3P2YcBI8lbgLzXa45JLNERZi7xaS/GQXSJ8HkbK6IGhilfnHTvJ4yYk7qKeRrjkByz3npE0It39HHUAo= X-Gm-Message-State: AOJu0Yy6HdzKFiWk3/6mTFHHZtDggxU8YBcG7YnBifFzLMcqEeugJ9Lq XR1FanT4QiRrDGr+rOjtEDLytiLX2CX+MyzaV80kiH57BF3HsD2cUZFkE3SAecEOZbBhi4xQIjs c4WGeYxeQyllhwadHy7yOyaExxuQ= X-Google-Smtp-Source: AGHT+IFmyqM0n36CuBCgp4+9MlTTewpOjvy1XhbCATkx/SyHg8foHFQW1y1fhhdZR0oNy9184AxbZT5JpXLd37GpdXg= X-Received: by 2002:a05:6102:cc9:b0:495:c53d:d6f4 with SMTP id ada2fe7eead31-497599d7602mr4427066137.29.1723665138763; Wed, 14 Aug 2024 12:52:18 -0700 (PDT) MIME-Version: 1.0 References: <20240814171800.23558-1-me@yhndnzj.com> In-Reply-To: <20240814171800.23558-1-me@yhndnzj.com> From: Nhat Pham Date: Wed, 14 Aug 2024 12:52:07 -0700 Message-ID: Subject: Re: [PATCH] mm/memcontrol: respect zswap.writeback setting from parent cg too To: Mike Yuan Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, Andrew Morton , Muchun Song , Shakeel Butt , Roman Gushchin , Michal Hocko , Johannes Weiner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E3FF2140003 X-Stat-Signature: 4c3gshn1394e5oicjyq7b57pu4ypuoft X-Rspam-User: X-HE-Tag: 1723665139-651596 X-HE-Meta: U2FsdGVkX1+fLaYgrxB4DnhkR/wa6qXjMrEA6gvyInLwECYgd0YJIzfvjtZYd4Q1F7wYUVQDC3xtUSeCChcAdA4gpwDpVd3Hs57eSKEsYMMHHCAhpHSWbPkOmKVchKe+fxe2f6S6nHgGc3LYUfhOn/OQE1qap9W5Ub2dFbq4ngtcnMWOWlRMpxVUkYeuf0G+PGr6k1q7FK2UZFhGGiJ1R+W0V/ONdCVBGiNGAdpQ9r/v4XoN+9XRrBvpBmm+u4FHEE03ADS44f3qyCbRAFiCuWDoPgr3UQT0z/FpTIuZV7jArP2Tjb9wybvPHBDtNyyL2crhyPaPzcCCTi5Hm3uI255xldT+UjcWPLw/i+rHS2aJjQ2eeBN8r+nOAHeqTBODWvoYszVXJExsH2KoMQr51gBtE+C3H5stK7lD8BeNG64gFneusp28LBjnFKGN0Seespp3UoxmjAp2eW2phLD3vfMVwr7/n9goJOq3uJm3TBKsWmZKfuVkqFoV2zpvW08u0hSwvRGvlvcN4JHor/kD/KENzfqlRFd1nN64g4FHZXDRBtxQU5kjZhsqxpMSullrWt7vSd9x2Yl4v0zFGgZ8RLjNJyFxAFTas1mTJqfxyO0XQBrRCV2QrFFriNdpQN7dw6vYwgwfiPr/ikdcsmlRhF1jFaNUOG4klJzVWd5dZdaZnGW8UFdWBXlKBgyIXdpU0Pn6StdUSQyMg9fC1tJsAhUfhTz+p9Pe5/P7ALLjh+FZ2uqf3+x763DUHqKRgdtqhnplNmsIC1a4IbkA388CF0WVVXlLAqCP2PPik5AP9+1Y2Vhp8Ag6aox9xd5NoT5+GKOmE0yK6/7wuABkpbAw++KS2cRplAbufVZRRzNzWOIZn/1t/fQ82nxOBEdGXg7i5f2mETJxJL9x7pPPURg57VlOrdIDRBYBfU9EY2ZGK9CypvzZBAdcyg4h+kMoz4CePUwOIfGRczz1J3DNptk wWYxlgNL HHbHqLdW+MD9FmobWblnAzh88fxBXV5ngAtQCt1pmPrHLWtK7eche5c1n1HUHEeKq8vPFipUivaQHw8mcL8f4zKjN3ncHDQo+0Ai2O6oBT5jqjv00yT9mFwkQP81Rc5S0RUtA+e9BTwKTHAvjvzlDKU/ajl3nR8s6C267xqlkGGgPKDPraFM4mQkRYtJMNboMNSS3Kx8d5SkMB2Hig3Nzysl7WffIR7LD5fFBQ+Uatvvxkwb71z+yVa0cPYI3/l3M2ESvmqKB+8asaP49hIopnpue3F71El6Xu4E0YHPXfh11YOptzxmWN6wm3crPsue07rok5bmNmt9fPy5mWe+QA1ncEJzspoinEajTaWuZHYb6niLQLNeylOgd19G1K0O5ieuhviwH9J3fN39BoAecVjvmxg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000009, 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, Aug 14, 2024 at 10:20=E2=80=AFAM Mike Yuan wrote: > > Currently, the behavior of zswap.writeback wrt. > the cgroup hierarchy seems a bit odd. Unlike zswap.max, > it doesn't honor the value from parent cgroups. This > surfaced when people tried to globally disable zswap writeback, > i.e. reserve physical swap space only for hibernation [1] - > disabling zswap.writeback only for the root cgroup results > in subcgroups with zswap.writeback=3D1 still performing writeback. > > The consistency became more noticeable after I introduced > the MemoryZSwapWriteback=3D systemd unit setting [2] for > controlling the knob. The patch assumed that the kernel would > enforce the value of parent cgroups. It could probably be > workarounded from systemd's side, by going up the slice unit > tree and inherit the value. Yet I think it's more sensible > to make it behave consistently with zswap.max and friends. May I ask you to add/clarify this new expected behavior in Documentation/admin-guide/cgroup-v2.rst? > > [1] https://wiki.archlinux.org/title/Power_management/Suspend_and_hiberna= te#Disable_zswap_writeback_to_use_the_swap_space_only_for_hibernation This is an interesting use case. Never envisioned this when I developed this feature :) > [2] https://github.com/systemd/systemd/pull/31734 > > Signed-off-by: Mike Yuan > --- Personally, I don't feel too strongly about this one way or another. I guess you can make a case that people want to disable zswap writeback by default, and only selectively enable it for certain descendant workloads - for convenience, they would set memory.zswap.writeback =3D=3D 0 at root, then enable it on selected descendants? It's not super expensive IMHO - we already perform upward traversal on every zswap store. This wouldn't be the end of the world. Yosry, Johannes - how do you two feel about this? Code looks solid to me - I think the upward tree traversal should be safe, as long as memcg is valid (since memcg holds reference to its parent IIRC).