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 07CA4C4332F for ; Thu, 14 Dec 2023 17:34:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9263A6B0428; Thu, 14 Dec 2023 12:34:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D66F6B042C; Thu, 14 Dec 2023 12:34:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79F0E6B042D; Thu, 14 Dec 2023 12:34:23 -0500 (EST) 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 67FD26B0428 for ; Thu, 14 Dec 2023 12:34:23 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2AF38120BEC for ; Thu, 14 Dec 2023 17:34:23 +0000 (UTC) X-FDA: 81566122806.15.A1DC2A9 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by imf19.hostedemail.com (Postfix) with ESMTP id 595C41A0010 for ; Thu, 14 Dec 2023 17:34:20 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf19.hostedemail.com: domain of christ.li@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=christ.li@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702575260; a=rsa-sha256; cv=none; b=PPY7N9DWUfKpqM77eaoe18ruq0udbf6PlUYy5VUonIk06E6T5xhm91krqQY1/BpY7JLuVe Ltq9rL/CLJmlemAdDoi5cA0GQhyBQo/sFsZwupOxfMZOzvtYHnHbPYjlCLPUBDxi12bRSO YoWx+ikFnhWLID4LbtYQbeXnfPz9G+U= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf19.hostedemail.com: domain of christ.li@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=christ.li@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702575260; 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; bh=/I1W7e0WksPQr4B0ossVVfyuwCWdZSDTARqTZ332iVA=; b=qTpLbhodthuLKKLkS7GkV9uNrx4zjktGFbXqdze6oz7Hc6U7ndWxNUj0M8cGeCgb2Agu9M LJfXepMUiTEh/A2IY3GOf3FOZAMTXTqJT8d3cn1CJ1PM6a9BGd78o2Tp2mNW/ypr6zym/+ Aghk4yKx46YWXHdJDlthOgaFmt+2tII= Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2ca00dffc23so107384901fa.2 for ; Thu, 14 Dec 2023 09:34:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702575258; x=1703180058; 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=/I1W7e0WksPQr4B0ossVVfyuwCWdZSDTARqTZ332iVA=; b=XSiODIYvlJ2cu/NGCuwrpgA6EXYAcn3LYJ2ER2har6unlOuAW7dQmm0G3lnopQjiW4 aOx/AextcwMmtvfwn260AzwDdqsKAQmsFmb4SnBupmMMk4s0uMVXsXG3MhCZqySRpsIg ybv1QbOIfqLJ6MPtBcOaQZS2a7KibrHep3EwoAZ8UTUg5qB8LwndQgnP/d47Q6y+w4jv ibfActHfdcuOoIxeuTVlJ0DlzntxUqlr61ruuz7zOFHJELZXKoBBkSfCLWMEoklIE0Zf KSD5+bBbFm0ArNPCqjn3JFAu86ThpqZ2RbT7+fcqzVitcjIPZJl3oc7yiPjp8AStIHr4 Io9A== X-Gm-Message-State: AOJu0Yw8zK4F1GjIxvXsA5EtSZFPNmnkhlHho6B/s3mb+osYjCrL3ULq LCi0IZYONDZnYX2mmkt4ufrOXrway2heR79dow== X-Google-Smtp-Source: AGHT+IGp30y/H8P//ZOKK0ZSEtOYUDKVBBp+xHmSJODVndRI0if5ppAbKb6uab8A8wMFFgIMHH/LKKVpMRst2iIg9nk= X-Received: by 2002:a05:6512:148:b0:50b:f858:f132 with SMTP id m8-20020a056512014800b0050bf858f132mr4870323lfo.132.1702575258112; Thu, 14 Dec 2023 09:34:18 -0800 (PST) MIME-Version: 1.0 References: <20231207192406.3809579-1-nphamcs@gmail.com> <20231209034229.GA1001962@cmpxchg.org> <20231214171137.GA261942@cmpxchg.org> In-Reply-To: <20231214171137.GA261942@cmpxchg.org> From: Christopher Li Date: Thu, 14 Dec 2023 09:34:06 -0800 Message-ID: Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling To: Johannes Weiner Cc: Minchan Kim , Nhat Pham , 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 , Zhongkun He Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 595C41A0010 X-Stat-Signature: f6f35g4kaasfse1f3wo488weuy9prexr X-Rspam-User: X-HE-Tag: 1702575260-577238 X-HE-Meta: U2FsdGVkX18viz3f2kEOKcPekjWZk2GWEbq0tnfgonReWS7QKYBZK5GhggmypdDZCu0dYzpJKCl3i1uPm/B76ubkj3CjdHt3R+yAb4Oxd0PDdrA4H12TWQyg2Ji/yJai6BHwBYBbViUHcK9RUNzgC3SgbaXLzmJoXmzPIslDdtDseMayQkNuktm8F0RNdFFQw6GV4sxUsbKX6zbRHukDAT2NatQWqmxicte0BAwJJtDKsHG6vbfsTLWU/6fdoYHFOGiynm7ezRX/fBpvVnWZgG45crjqUKv79GCkKW6NuUVgYSrpkJj042LRXhXwObqN6Xz58vm/ojMGqdGjSFEcTlSzvMAt4OjvKKQQRrCPq6jAlpCouPz/LcutNmlZxuuRkCGS+xnGr2CAcnUav8AHnCEMvJki/ERphJl6H8XhTOc8SFWUbm/LChmsThbkQPUKaK3NaQ/RrzoswUqhR81DtBJGDURH3sDOQV7OyBT40T6LuMMpuKJjEhigeXFg/GDe4TvR+9Tk3A1OvHBGnOMjX6h/6CnkbFBOsjWW3vDtcsJT8Tde+sAFaY4ZEEY3Hf2ol+yABw7Q6Dljc1RHoj3SDnbEHCj+IbyTjf7SoWbftSggr3i2qZm+ArFKWQau43bSG/o6XvbIPxjUXZ1UvuLlxlOf8KcDRyQazgFa26y0QtW2+qi7l28W4zQYZr1p+VxBMZoMp5poTNr8D3eHC3YCKFIfsJcnaSuhiTVyZiMfEaPLehoGLY0akTkZ1ayo4vGi141NaQQ7d1E0NTkBYJE+IFAQxQ11DPPjmkJyk0+zCUWCRrbrvLHCqj5SDUfumUimOM+RLuw6ePDI78VMjgy7MLyb3I/MApnmNBgYQOJh98+PTUyPkBH8XCIW7jrYaXNmKmqy1U/+VRXqRsReu4etuJD22SY6Z9HRi9QjMwWJmw7Fg+uY4XWNOFOMXmiemrCq29oyg630v2ADP8aiLnx qMlGTBrv k4ORDYC23D9Xv51ZdTWfVrzzdILzx01NLp5SroTXjQmxy19+HdZIj8RpMgLh9+7bf2kwIbmbdu0ybD2VhS3YKTUlIUJHdcdntzs7Fw1C8xcwgWRs2yzRq6K7F/0bSfYm0fvEe+og0a8j3jjXnyk6ak3rNQOCHon57GSzU3EQZaUKJ007clbDLkXhAgGHV4evbXWkzAYxII9jsdpPVwyMXosDAB4h5AAGrukR1moAGK9NQe+fYY7nJ6QwCKQkHsdxZS+WK2iVeuhwaUGmVJEESBskyWYDqATCL1ayhnK1y+0rUt4X5DNuwGmTCJesAb5f398whBtDZ01IV2Op3SOdIKWQRxgrA0klv+uFUs8fEvNBCJuZ7T4DCRreYhpUHLRxgouJMfdpJ+O+BkvqMDKN8mxAGM1cNAPvhLVTCBcu/DX4E1WnXSGLm3Z/x4Q== 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: List-Subscribe: List-Unsubscribe: On Thu, Dec 14, 2023 at 9:11=E2=80=AFAM Johannes Weiner wrote: > > Hi Johannes, > > > > I haven't been following the thread closely, but I noticed the discussi= on > > about potential use cases for zram with memcg. > > > > One interesting idea I have is to implement a swap controller per cgrou= p. > > This would allow us to tailor the zram swap behavior to the specific ne= eds of > > different groups. > > > > For example, Group A, which is sensitive to swap latency, could use zra= m swap > > with a fast compression setting, even if it sacrifices some compression= ratio. > > This would prioritize quick access to swapped data, even if it takes up= more space. > > > > On the other hand, Group B, which can tolerate higher swap latency, cou= ld benefit > > from a slower compression setting that achieves a higher compression ra= tio. > > This would maximize memory efficiency at the cost of slightly slower da= ta access. > > > > This approach could provide a more nuanced and flexible way to manage s= wap usage > > within different cgroups. > > That makes sense to me. > > It sounds to me like per-cgroup swapfiles would be the easiest > solution to this. Then you can create zram devices with different > configurations and assign them to individual cgroups. Ideally you need zram then following swap file after the zram. That would be a list of the swap files rather than just one swapfile per cgroup. > > This would also apply to Kairu's usecase: assign zrams and hdd backups > as needed on a per-cgroup basis. Same there, Kairui's request involves ZRAM and at least one extra swap file. In other words, you really need a per cgroup swap file list. > > In addition, it would naturally solve scalability and isolation > problems when multiple containers would otherwise be hammering on the > same swap backends and locks. > > It would also only require one, relatively simple new interface, such > as a cgroup parameter to swapon(). > > That's highly preferable over a complex configuration file like > memory.swap.tiers that needs to solve all sorts of visibility and > namespace issues and duplicate the full configuration interface of > every backend in some new, custom syntax. If you don't like the syntax of memory.swap.tiers, I am open to suggestions of your preferred syntax as well. The essicents of the swap.tiers is a per cgroup list of the swap back ends. The names imply that. I am not married to any given syntax of how to specify the list. Its goal matches the above requirement pretty well. Chris