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 E5155C4167B for ; Tue, 12 Dec 2023 23:58:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 365716B0248; Tue, 12 Dec 2023 18:58:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A2446B020C; Tue, 12 Dec 2023 18:58:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F7546B0201; Tue, 12 Dec 2023 18:58:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E00546B01B1 for ; Tue, 12 Dec 2023 18:58:28 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B0061140B17 for ; Tue, 12 Dec 2023 23:58:28 +0000 (UTC) X-FDA: 81559833096.10.926841A Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf15.hostedemail.com (Postfix) with ESMTP id A654AA000D for ; Tue, 12 Dec 2023 23:58:26 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uXN29BNc; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of chrisl@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702425506; a=rsa-sha256; cv=none; b=cdU7LFhajMflLCz0lOTBHrOQy53jiqDavpkmhAxKPM+kk7esf1XVog4qNEA0IAvbF8VuJm /+TNE7UItqtGoJQKY7Y0ZjDSR1rjGAz5ItOVduFO/oyaDuosvQ/zlOylVkQcZ/lR8Iapw3 LMJlyplRaQ50NVQK8fzJopulAcdz/qc= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uXN29BNc; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of chrisl@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702425506; 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=hPz99cd9ncMhdqhEOW52ymvh41nJ6piVW+kmsgXYUQw=; b=w0lxuoEoHTKoScrGKlzB1CcggLLxQggyqDkfo1aGnrjxjIIIbfOcJ0zO0k4BVPfsYh0hUE rz+UXQxxRUSmA24fnJqdmoPKoyuKPRYbsSI8m7y2cja+NBahZ4iqVzi1XgYwO6m0hr8T27 TMPZzMR2SGOa0FLB+JKKQ+SZcqHqdQs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id B4586B8172F for ; Tue, 12 Dec 2023 23:58:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18726C433C9 for ; Tue, 12 Dec 2023 23:58:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702425504; bh=hPz99cd9ncMhdqhEOW52ymvh41nJ6piVW+kmsgXYUQw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=uXN29BNc1wW3MHydt/a5ostC/bbsjV9exXkmVGhzvYs3RaWt1pypq/i80IgN7pNWp TtFL/mP+MUvAuLX++eFkZTYJF9o9dUT9N2eEH5UNwFAkHGvdIa18qmE3+uTS6Rw93i Vz7IbGdITYVBWtB2enE7Pb6OM8no+764vOz+N8z5fTHipSqjRVxeyx5bIYrNIfnhBo Gd9B6gXfyR32S0854xczVTAxjZO1j131Zi0ov2X/TO4r0AfDvWiKVPa9FH1a+BbFlw NV0bqdODbe5IPdiFeOhpAyoi1L4Df17OmL/51GfOaw6nOiOvcBFphD/6PqOcY/daLD +sezSRrJ/uDWw== Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-4258c2e2ee7so45871511cf.2 for ; Tue, 12 Dec 2023 15:58:24 -0800 (PST) X-Gm-Message-State: AOJu0YxPaOmQPGzi7TngAEGnvrINdoL8oGmvfy5tUD1PKAADq43gZ75E 5hUVKtetKSNNcl/j651aft/xyzqWATADv0+L6AeRVQ== X-Google-Smtp-Source: AGHT+IGOTnckQME+eVCsPSoeGOyMFBoqjkzOWlCwSBsc7t+BIufubWB0ct9OeR4xELFwTaEK+N63aLRDaYUgcs98klw= X-Received: by 2002:a05:6358:7296:b0:170:17ea:f4e4 with SMTP id w22-20020a056358729600b0017017eaf4e4mr8579237rwf.49.1702425483026; Tue, 12 Dec 2023 15:58:03 -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 15:57:51 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling To: Minchan Kim Cc: Johannes Weiner , 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-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A654AA000D X-Stat-Signature: mwknbp1uzk11djmju9dhg4k8pnb7pjd5 X-HE-Tag: 1702425506-598860 X-HE-Meta: U2FsdGVkX18TfQlQhO+AcI0IzonnNxSq/wqU3XC/wFohleGoPbu3KgcSYWEIzYh0oXOj8FMFNU18t7AOpo2bSos294ZqtqCSbDps0v5J3Lkb1TCIKbOGQjC1i97eNJpzdzvmmuDYnF7+ID9y+FaTlC99xopYDNqEe5gCRdmABtXwmRsPpLyIIBjIDFjVR9DQhaixvnqCVG9oWjdC8aQp7KQ9OV+tFbe2q2hS7SmhTrkycaNsU7ymYni2f4e0SEdvOTNitXpB2Hgw7IEClDQuCTy+bJy2YMjoOPUL5K1oQztzqr3Vdz5+s1ciWNmlxFNyp/aua0U5OjNhW0Ta6gE94tXuWX+2GBeDq0IxGpCVGVU+E7NAMOBTlajTGuCSySPzOspbczUDr8QUd6VspXB5uvn8dwoSfBnTMoJ9Fpqe2uRDjn7sCa1u615DEhe5T1ciBmHrMTnYWADmkp5ICzVC7RD+iYv61Pd1mjooXGX1ZtKA7eUqZ4mvOBgdJy2px6l0nbGTwrVD2BtlkVK2jMZ/Ex6LT8zqjOXqRsjrD0eI2Xoqu+elElwEKsH3wywrs2HJHsXUa8qq9wRfANZ1dIAUZApc897chaonwz7XK4n3UEZto7k082ofvOl3gW+PVd6Dpu1rTXDchb8BhoTKd1RIe+oR8nPYAwWuwy74NzTgsCww60q1elNTrVSn0xhxZV6ezCt3y18WomGRrknDFLR5HFym/vnWI5OdY2r99GBNhFbaU5KMeQhtGpAgkXQVn8YSlOx/99JFFVqc9YeOmO0Y0quE3XrgTP0SpqhFNGpk7jGgjbwlLs/Dx5Ox0X8fMG6iA0I6wII92HgQpfHWXbpQWdAy2BouBNBKeX05hUKp85TF5YTVWGcobV4GMSyk0PSmWAUuhbR1BoM9GQ7Nv7bQp5lmIiGQ6JQtuurMn+gYQ9NYKGP6Nee/vDscqlWIT8EjfmxkIdB2v45EN1sPkMk na7jh31p 4H7bA7yyPKNAUV5wTRxigl6eM9cEo78Yw5XZBEDqo8yVa3f91oO68mh/gPSuxr5Tn9GWMZCFxipgCfjne0HjNWTqjOtCX3JjOUofURtP7C/9cZ273Ud28H45OCcSV1uSyqXLudO+7Jnt3N5crw2Ub9GVAoMrneW0h32etdgTaRzUGfRgNgsz/bwfM6QroIjxkXPJDB66FwGHwE1J3sYAhZEZx+/RWx6HpX4Ed43qN56ZUqiS8e+f1RUQdflDurPDAr/y9hEztYZe4uxIEAH5tRxEGBQ== 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: Hi Minchan, On Mon, Dec 11, 2023 at 2:55=E2=80=AFPM Minchan Kim wr= ote: > > > 3) Android has some fancy swap ideas led by those patches. > > > https://lore.kernel.org/linux-mm/20230710221659.2473460-1-minchan@ker= nel.org/ > > > It got shot down due to removal of frontswap. But the usage case and > > > product requirement is there. > > > +Minchan > > > > This looks like an optimization for zram to bypass the block layer and > > hook directly into the swap code. Correct me if I'm wrong, but this > > doesn't appear to have anything to do with per-cgroup backend control. > > Hi Johannes, > > I haven't been following the thread closely, but I noticed the discussion > about potential use cases for zram with memcg. > > One interesting idea I have is to implement a swap controller per cgroup. > This would allow us to tailor the zram swap behavior to the specific need= s 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 compression r= atio. > This would prioritize quick access to swapped data, even if it takes up m= ore space. > > On the other hand, Group B, which can tolerate higher swap latency, could= benefit > from a slower compression setting that achieves a higher compression rati= o. > This would maximize memory efficiency at the cost of slightly slower data= access. That is a very solid usage case. Thanks for sharing this swap backend usage story. It goes beyond my original memory.swap.teires idea as well. We can have some zram specific knobs to control what compression setting is using. Moving data between different compression settings would be an interesting topic. It might fit the swap.tiers usage model as well. I am just thinking it out loud. Maybe define different compression settings as different tiers and then allow the cgroup to enroll into one of the tiers list. > > This approach could provide a more nuanced and flexible way to manage swa= p usage > within different cgroups. > That is again very wonderful insight. Thanks Chris