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 82155C4332F for ; Thu, 14 Dec 2023 22:55:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 101A96B02BD; Thu, 14 Dec 2023 17:55:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A49B6B02BB; Thu, 14 Dec 2023 17:55:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E87606B02BD; Thu, 14 Dec 2023 17:55:29 -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 D353A6B02B9 for ; Thu, 14 Dec 2023 17:55:29 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9F8631201F3 for ; Thu, 14 Dec 2023 22:55:29 +0000 (UTC) X-FDA: 81566931978.09.B7F0C78 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id AF27B100021 for ; Thu, 14 Dec 2023 22:55:26 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aanm9JAy; spf=pass (imf05.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=1702594526; 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=Grf7p7fPCkEqN65KUDfnN0gBmOwNPSpfdD7NmMiKon0=; b=aLLxfDanORDU+OxnjGPMS7/bVoKqazj3Uu8kL0+yyN+aiJucNt63TZIiqQPWnDUoi+UuoA O24rYWsF6BZFFZ8Zhxr1VOJzlAzgtI+t1HOjMfpaJTM+FOefYWxyqoBabi9t5jh4pdSg8n OfY8uPUUbNIIFXHG2N9OZYgZMUIAtwI= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aanm9JAy; spf=pass (imf05.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702594526; a=rsa-sha256; cv=none; b=FRjEyfVUNZkf8Arl5BZ21cpFyTRmVshGGDlfkkUQMtlnG/xY/Je/5GTGkch1joF9La+MJL m1TQIcg/zOhoynhjmPbcFNUuzf5v1irWPgj0Jg8BOaXMbTCLo7nzNVSVkNXqbqMJXhQVd/ KFVqK4/Xma60uITCG9nyXnaH+5b2mX0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id DA93A623DF for ; Thu, 14 Dec 2023 22:55:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8AAD1C433CA for ; Thu, 14 Dec 2023 22:55:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702594525; bh=Grf7p7fPCkEqN65KUDfnN0gBmOwNPSpfdD7NmMiKon0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=aanm9JAy69Sib1BK5Fzhdjbb9cUqxvaGMlD3VIdYUHVJ8DyE2waKVYJDG5IDrlhUZ NH3XErRtV0OEOYqmb7xVb6asME69LJyrvuzF3hudltBuOLaZeT4m+Znm7OqgWNn32E 1EG8zXpCsfgk+Kr9s4DhXjb9KdqrPGnVi/tlKEXgj9HYYB7WpZM5n4O8+KSqi32SCl ZhSI6Fph8j2OLLlZHO/pfKK9jtOt1BXsmCbZr+u0ZxhhV+zLEpPAGA0r7X6eafHA8b xUseSw9i+Te45fo3DR36hbuS+14wcOj61tN6hspBWqYrFNQ6ZYOireysRgmECeuMrI YTELRnBTLI99g== Received: by mail-oi1-f174.google.com with SMTP id 5614622812f47-3b9dc3215d2so50953b6e.0 for ; Thu, 14 Dec 2023 14:55:25 -0800 (PST) X-Gm-Message-State: AOJu0Yy1BFoUXU4u/e9pKh6d3TyyKxtX11mJw+KB4SWlpr6RogjkhYeR /1fscArD+vDR+GAIkmrpIEeK2tpIReOnzkigHkyf8w== X-Google-Smtp-Source: AGHT+IG/TtHGU7JVw2TZsapT4A3vzYF0UL0RzdAkU+Dfl1UY00/kcl+wiH08OnNQ1vnM6rdLPBxBSvf2V30zZrft7aE= X-Received: by 2002:a05:6a20:4ca2:b0:18f:c21d:7ec4 with SMTP id fq34-20020a056a204ca200b0018fc21d7ec4mr10153997pzb.40.1702594503804; Thu, 14 Dec 2023 14:55:03 -0800 (PST) MIME-Version: 1.0 References: <20231207192406.3809579-1-nphamcs@gmail.com> <20231209034229.GA1001962@cmpxchg.org> <20231214171137.GA261942@cmpxchg.org> <20231214221140.GA269753@cmpxchg.org> In-Reply-To: <20231214221140.GA269753@cmpxchg.org> From: Chris Li Date: Thu, 14 Dec 2023 14:54:52 -0800 X-Gmail-Original-Message-ID: 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-Queue-Id: AF27B100021 X-Rspam-User: X-Stat-Signature: gqnioihugxj8cr6ymy5agmggtrd3da5f X-Rspamd-Server: rspam01 X-HE-Tag: 1702594526-942234 X-HE-Meta: U2FsdGVkX18DCpxUJ90EA0xmm75Q0Hqk8VC/1iNcw420G777sBKW+WBIsxpQzHIAojrRWNMY+QIkUKN7N+EUsNIcDLxpN8nFzQWTGbTC3e2hDxtO807bruqk8ayod1bEKcGkySOZc7R4G5UpCuPFK9n/mK9eZE0Dv+9kqNM55P6YOYLiVeSVUMEjrMAx46YqFFWvyLLhj4TJGc04/iPfIa1si7W5XsD3hrqdbJ0Mj2OgWGfRkL1Wrq0FBt/d+CvpyiGeylxlqxRPLVEpoP3nxMipgF28MWG9OiBTf7GdfhUCp1LS5gEKUyt5NKi1PFE0y2sl8Lx0fMSW3hCxFHVI7oqtliQFn+4t3miZF4YohTlKOCtSbFLIi0AlG0cKFD6+Ihhnn2zqHk9S7ydv6AOBvfaUqZX/Q0skv2YV6X1KSdzKREnKKAcpNHXTt8TI5AJgcQ7PfgQNBPvU3iDZ9A8ARr+LReSWSUTwdSCwvMFrvtwuwpYIa9cD+NubFIufKHHhmN2Q2ZuIheF4GF+B3cnNFYoHZLWIOYoiu1v5W5n4LiQL1TltypDY9GLrhJlD6ucwZ0Cl4nMLdPv+LZiVjwvNHnZ/u2+4JpcfUyYUTp3pWiyFz824XZ4B/XlvAbmfpSPwH+V75cXYEc7qwiec1EFASR4NLEUSdaadajGzXAmfiIlkAS7uBcKiQ6lkZ3c9o9MSXGr419/xqHZi5Ni2jK+zPqhjENj+8kn3C6RK5NCFKRJud48su1x7WdYUkMgE5VbMMS2Np75FPYgmJgqi/U/lA3OXlIq1MOhQG0fd1dbCOZhBTcxVTImrQx8cnMeVSLbUL+ggr5DEpBpBdBhgsyIi/7y4pdmfMxX4G4UZbses8rq8Jgy+J+8SgymP1IMNy5z+Nh0BvyKyuzf7Lp48eTGOVFa86wSzak43loXHh32bYRUYoFO5LKc/I52ZWVEBv1dAwGJ8yBTv5iRSuIJlsjr 6HLvXe0a 4m9opSs+vxXZxkHt8U6dSVJ/J5GeAbujOZi0/ZIz8mPtaG/LrAuxybLhnrkAOVUfpTSwZmSkA+VTdf8gmYAtr53TBlZJpGJmdB/3TF6KwLABpbMUqaMn9M20DD/Oa4dD+8nY2Z3z5RzKXpI4/2pGMf0awGkvuPn44F4kE1X2TmXzS4WjV80eyr3xuyChvU8zuKqZOyVffrH4OSpKQMeUgLFAQQIVQ6/2AH9D+GvIw0joMPo8/mYcm4OJjn4GDltqiC+WKvQqLJ2wkqkfpmw1QXITyvQ== 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 2:11=E2=80=AFPM Johannes Weiner wrote: > > On Thu, Dec 14, 2023 at 09:34:06AM -0800, Christopher Li wrote: > > 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 disc= ussion > > > > about potential use cases for zram with memcg. > > > > > > > > One interesting idea I have is to implement a swap controller per c= group. > > > > This would allow us to tailor the zram swap behavior to the specifi= c needs of > > > > different groups. > > > > > > > > For example, Group A, which is sensitive to swap latency, could use= zram swap > > > > with a fast compression setting, even if it sacrifices some compres= sion ratio. > > > > This would prioritize quick access to swapped data, even if it take= s up more space. > > > > > > > > On the other hand, Group B, which can tolerate higher swap latency,= could benefit > > > > from a slower compression setting that achieves a higher compressio= n ratio. > > > > This would maximize memory efficiency at the cost of slightly slowe= r data access. > > > > > > > > This approach could provide a more nuanced and flexible way to mana= ge swap 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 backup= s > > > 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. > > Why is that a problem? It is not a problem. It is the necessary infrastructure to support the requirement. I am merely saying just having one swap file is not enough. > > swapon(zram, cgroup=3Dfoo) > swapon(hdd, cgroup=3Dfoo) Interesting idea. I assume you want to use swapon/swapoff to turn on off a device for a specific cgroup. That seems to implite each cgroup will have a private copy of the swap device list. I have considered the memory.swap.tiers for the same thing, with one minor optimization. The list is system wide maintained with a name. The per cgroup just has a pointer to that named list. There shouldn't be too many such lists of swap back end combinations on the system. We are getting into the weeds. The bottom line is, we need to have per cgroup a swap file list. That is the necessary evil we can't get away with. > > > > 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. > > Except Minchan said that he would also like different zram parameters > depending on the cgroup. Minchan's requirement is new. We will need to expand the original "memory.swap.tiers" to support such usage. > There is no way we'll add a memory.swap.tiers with a new configuration > language for backend parameters. > I agree that we don't want a complicated configuration language for "memory.swap.tiers". Those backend parameters should be configured on the back end side. The "memory.swap.tiers" just reference the already configured object. Just brainstorming: /dev/zram0 has compression algo1 for fast speed low compression ratio. /dev/zram1 has compression algo2 for slow speed high compression ratio. "memory.swap.tiers" point to zram0 or zram1 or a custom list has "zram0 + h= dd" Chris