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 4716EC4332F for ; Wed, 13 Dec 2023 00:29:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B1BE66B0419; Tue, 12 Dec 2023 19:29:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ACC9F6B041A; Tue, 12 Dec 2023 19:29:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 920326B041B; Tue, 12 Dec 2023 19:29:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 74B746B0419 for ; Tue, 12 Dec 2023 19:29:24 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4E91780B84 for ; Wed, 13 Dec 2023 00:29:24 +0000 (UTC) X-FDA: 81559911048.05.174FFBE Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf16.hostedemail.com (Postfix) with ESMTP id 6BA6A180014 for ; Wed, 13 Dec 2023 00:29:22 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eMw9KJ0U; spf=pass (imf16.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702427362; 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=T/CmYAMX8vCFXjdnC4Q6viaedqv85SFFc1KRj8TomIU=; b=6ejDNE+9PR8LW1i71vBBWjbZp9l+v1g9G9OsHRiFjbdu7CQALZnXWToXADnPq29B/pRUSW HPMXni3TSBOnuJ5M4PYgrlZap+93tDpPs04mx+yLZbLTl7oJQYuw1Wg0hV4JYXCW0WPi/I /kcuIskocCVLM3uNrmzQrv0E42IfgBA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702427362; a=rsa-sha256; cv=none; b=QDIzMoroCte7gEjJXDe638oEF3+eJWsarUoAysoQmMYGZh8/HoszR99hWbSiYBgFvsuHOa Re1+8uPKO3D6kGzWB/TRf/olVc9GwN3zV6z5OXkj45464yoy0HcutjBVkTO5ZRwevYVe+r 5zb0KdLE4E5eyUMJ5WNoz37n1+XRfNA= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eMw9KJ0U; spf=pass (imf16.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9C51661AA3 for ; Wed, 13 Dec 2023 00:29:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72C89C433AB for ; Wed, 13 Dec 2023 00:29:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702427360; bh=T/CmYAMX8vCFXjdnC4Q6viaedqv85SFFc1KRj8TomIU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=eMw9KJ0UWBQCLwJucNVACPH+suQsl6RVNL1OG80y3YaNs1CaiJvqsje8d+Et9x108 6+1Fm1evinGlFXu1VVb5tY4JM4OVeOYtxhdqPV8kGTDfYEUQ6i01epxbvA+wECwXU5 l+jsTo1zyoNOC/slDUqyx8vtwqyCUhIQyid7AfW883poyfHRsHqxj2KAV1ixa1z/Ld xYc831dwUUxnDUdL3a7R5xz7DXVVereJUHiDK6Hy8+fWWP72YoE5TMGT1H/T/V/k0e gWCbQ9DMHlSeny2eu2Dga4SGquzkp60ZC2c5KkzmNQwrVshGzlqZfATZytKAcaIUye sqrxwPo1UOkAg== Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-28abda9ca94so1375025a91.2 for ; Tue, 12 Dec 2023 16:29:20 -0800 (PST) X-Gm-Message-State: AOJu0YxBFhu0rGz0RWOzENSPGZdOYxvESeg12l8JD50fvtIgZG2w7OiI 8R25grc8O6KkDNuxxLsH7f2yUqRCgE7SblVuQzSfig== X-Google-Smtp-Source: AGHT+IHhKw+F52efRkHsVLmg7lTUhGeCsoBO3yLahHcCawGpwe2Hdh9DkMSCDNnH5zXB9NvA+lZSX9uYML1rHZWNnfE= X-Received: by 2002:a17:90b:3a8e:b0:285:adb0:de3e with SMTP id om14-20020a17090b3a8e00b00285adb0de3emr5846234pjb.34.1702427359763; Tue, 12 Dec 2023 16:29:19 -0800 (PST) MIME-Version: 1.0 References: <20231207192406.3809579-1-nphamcs@gmail.com> <20231209034229.GA1001962@cmpxchg.org> In-Reply-To: From: Chris Li Date: Tue, 12 Dec 2023 16:29:08 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling To: Nhat Pham Cc: Johannes Weiner , akpm@linux-foundation.org, tj@kernel.org, lizefan.x@bytedance.com, cerasuolodomenico@gmail.com, yosryahmed@google.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, Kairui Song , Minchan Kim , Zhongkun He Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: sy9qk3tuat63y6mhyq4zw5zbeithxowx X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6BA6A180014 X-Rspam-User: X-HE-Tag: 1702427362-357402 X-HE-Meta: U2FsdGVkX1/PfiR/8QfE/Wfx6Th6ZeSnLxapZx63At0jhbOJXxCWrOQRLFmhb93hencSbbKM/7c5GSnATjXzlWY4MmzfyqwQYQJA1JvUqjNcUYJDi8jOJtuLxDyLvs+YpWFzCObt3tfbDIPgvF79N3pYikUWn1T+twzXIUwLybmBMHFxGibZkoUNPej1G90RxopKQbIB0ZiRLejM/7JForUDWMtmxSI+OI6KZSa2onbUwF1hpHEteWs/I2ALEW7b/o3wNPtuhE2p5+6Xoh5y0js09AgADUlITbNj5XeuDhpoKnitRGLu1Q5UDz3oZDl1Be1xBCWz71iUnqrV9PGhNLcrGaO/h43sJDAJCoCQthHSDdDV+VCS0kHBHHWxNzm9UemFy1HlcKXq+MOZuEAHynwNY54gr4xPaeggUvuHGAoPLmtQHp8aWcLZLB/6oPZeOHUpHGIA6Bp2Quvku1cDY3f8Wwcf26Ao81dlQ+yevSioi/Xe1MJvHcoLjgkncCiGyPQf0AF80n28ionnPEe9JMsUJoeegNWx3E6jbiiwRqtMq5BgclCHLkZwTOSYK3PvrwboKinpAriPNs499D63+20+tJXmWx65dRn2nk++V9BPGj+bGtMrJbPj0pWsNhfXa8zxPtmmDGaxkWUyrK7ovgTd5+AkMf+4RxO/mttOeap/N2wb0Ruv7gC9jr9Y1SFmh03DlIHn8fYH8CgkP+r7sjzrRilQm7g9aU716hefOJkb+LLCoR3QzQ9tOu5fgs6/MG91mn4XrRQ3SLkggBQDjA80or3hFUdAmTQYYyiDLcXTgtfgSrMPjG6Fe5MeHrFtzFQmAA3R6fqFQiija2pS31Hzq9FGGSq/NYwihAJfBJUrbCdHifgGDk2pRteq8RKDrbpM/A4NJgV1morr6UjRTpw8Sn59GJjChWS93azoj6/heUpNFZ4aza/DliqZ4wkLa0Nf8NjAcsb0L+dyyTT avFz0kU/ rxnpgdkOCnzHMWEpHw6ll72ZeOak8cXG3YnkLaPjHjVEOiaftQern85DXX2nhVXZPzJF9iQTwG1E0Lv1nvuF2l2zdD46AJ+A3AuZ+29N0zAjOc5qwEi0gEf9QW5jGwJma+cmW8BlDo8yD9HZxHFpwHyfRYldNx4/EHsXfXPpErdGVtYFepnD66lAriPC1BhoHD6iyfVQD6U/psX5KtimmoyD2IqZQNEz/HQqTTnJSkQbwAbp0DGuAvelVPA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, 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 Tue, Dec 12, 2023 at 1:36=E2=80=AFPM Nhat Pham wrote= : > > Even if such a file were to show up, I'm not convinced it should even > > include zswap as one of the tiers. Zswap isn't a regular swap backend, > > it doesn't show up in /proc/swaps, it can't be a second tier, the way > > it interacts with its backend file is very different than how two > > swapfiles of different priorities interact with each other, it's > > already controllable with memory.zswap.max, etc. > > This is honestly the thing I was originally most iffy about :) zswap > is architecturally and semantically separate from other swap options. > It gets really confusing to lump it as part of the swap tiers. The writeback option is about interacting with other swap backends. So technically it is not zswap alone. writeback =3D 0 will disable SSD swap as well. I am not against merging the write back. I just want to make sure 1) better alternatives can be developed 2) zswap.writeback can obsolete if a better alternative is available. > > > > > I'm open to discussing usecases and proposals for more fine-grained > > per-cgroup backend control. We've had discussions about per-cgroup > > swapfiles in the past. Cgroup parameters for swapon are another > > thought. There are several options and many considerations. The > > memory.swap.tiers idea is the newest, has probably had the least > > amount of discussion among them, and looks the least convincing to me. > > Definitely. zswap.writeback is a really concrete feature, with > immediate use-case, whereas swap.tiers seem a bit nebulous to me now, > the more we discuss it. I'm not against the inclusion of something > along its line though, and I'm definitely not trying to limit the use > case of other folks - I'd be happy to contribute my engineering hours > towards the discussion of the multi-tier swapping design (both > internal implementation and and public interface), as well as actual > code, when that design is fully fleshed out :) Great to hear that. I think the discussion so far shows the alternative usage cases of the swap backend/tires is real. > > > > > Let's work out the requirements first. > > > > The "conflict" with memory.zswap.writeback is a red herring - it's no > > more of a conflict than setting memory.swap.tiers to "zswap" or "all" > > and then setting memory.zswap.max or memory.swap.max to 0. > > Yup. Care to elaborate it more? I don't understand the conflict part. I do ask Johannes in my previous email for clarification. One is the superset of the other. I don't consider that as a conflict. If we can have both to choose from, obviously I would pick the one that is more general and flexible. Chris