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 F2F30C3DA6E for ; Wed, 20 Dec 2023 10:22:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D7AC8D0007; Wed, 20 Dec 2023 05:22:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 887318D0001; Wed, 20 Dec 2023 05:22:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74F478D0007; Wed, 20 Dec 2023 05:22:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 63A8F8D0001 for ; Wed, 20 Dec 2023 05:22:39 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3614A402EE for ; Wed, 20 Dec 2023 10:22:39 +0000 (UTC) X-FDA: 81586807638.08.C8C5A5F Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by imf04.hostedemail.com (Postfix) with ESMTP id 544D140012 for ; Wed, 20 Dec 2023 10:22:37 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="d/3bsXHk"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703067757; 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=oRmWXSIwM0XGZafsEN4uRYb9SZntd9nJS61bvL/+JvY=; b=lqLfZShkXlLSBa8nuvYfYyNSgGGuykc7lpYQ4EoqCkRP9cdEyn0FFz3W22MUTnXlYkfNY9 DLJECmIrD2lji8gswmkEfkglsLRJGs1P799MBDHA4wTo5zCV+sn923nbL/MxgzrES3WMKo xh14HoDR8mRtQPXy5MsClDJ7fnmPKUk= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="d/3bsXHk"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703067757; a=rsa-sha256; cv=none; b=mhz3HkdGYKmy5OwWeV9rnjaFbDWhwAboKos56X5E//RqUqoGpBDS5aE5yLqEKga5csgmG2 DJ8quR2FILboT4goHWbcqC9O4rgOefWu8lekLvuK17yRSEbGEAPIdm+D0CUChftJwKsv4a YAUBuibvn41olUxX0Bw8EmrNgpAEIqo= Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2cc95f1102eso515811fa.1 for ; Wed, 20 Dec 2023 02:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703067756; x=1703672556; 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=oRmWXSIwM0XGZafsEN4uRYb9SZntd9nJS61bvL/+JvY=; b=d/3bsXHkP+oetg3FvtSoc9VHpNM8Hx3IHuUsJ3fdtdVunyDGgg2+aj74Q0+XKBOCPR 2gyjJB00I3zVeTRdnySDEt4Ppj6HH7YtEMLMeqtVFufndODHIUvnIaLZo0EvgZvzL630 M6MKll9iXDpvatW3HqRXdRu/HB24YJSE38qH54XGFBXaCqw3U2VIkyr14up3NDPhIm9c uX1J/ehUBYLmGaqvMql0U3nrT1fu7uA3Mvx7fr71LSCym6vrgd2bFma8hME7u/xdG8NQ u0yac8YMvzhr0Mnfw/vZ1Iw5S5hzRY+0uHMVyfXC2vBIwoh+JG7Z2L7NsXzAJIuxtxqt cEaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703067756; x=1703672556; 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=oRmWXSIwM0XGZafsEN4uRYb9SZntd9nJS61bvL/+JvY=; b=pnsT6n435oulALIc0/MRLrL6UQUHYWcLwwiynQTbJZgX4xZYP7F8V9fa9vXVKFy6H8 h69hz/89iyyBqQfdwwGiHHbBdHB7cAfAwoRNxdQlrganK1Ob6El0dmsTV2rJJynFGjN6 hlKxIKgd+JNpwflRtCUSDzpsl0WHtMoHd3FF+SUmA12gKQBiT8/3xEW0CPPYPYYv7JJX 8ixJ2k4EzJdj/bMe8QCgu5+TrvUKy1FH+g1BdkOPPAO0Od7Ln8lrWhIgWHaZpVj1mlfC D/3u/gUxvjB5RqtHbTowyaMPl2pkT5oi9i/aWpEUvbYStpvNa9t5IBNuGzvSd1RYS0KV YdMw== X-Gm-Message-State: AOJu0YxczNoOBRTDp/FF1lHB8GCJNUn7g2i9u9ntGrx441mLIN8ptIq2 o4ubLM/f1BK3THK+2mIYjrnaNFwS5xFHeQ+Ipjs= X-Google-Smtp-Source: AGHT+IFY1slTVVLg/kbuaZtj7R0eekl2SVbWCQXZ6Kx7su0RuehkbtHINgeFQCz4RTm8+g5CORjNhBOlmQuMg07uytE= X-Received: by 2002:a2e:9683:0:b0:2cc:68c6:305 with SMTP id q3-20020a2e9683000000b002cc68c60305mr2078790lji.81.1703067755538; Wed, 20 Dec 2023 02:22:35 -0800 (PST) MIME-Version: 1.0 References: <20231207192406.3809579-1-nphamcs@gmail.com> <20231209034229.GA1001962@cmpxchg.org> In-Reply-To: From: Kairui Song Date: Wed, 20 Dec 2023 18:22:17 +0800 Message-ID: Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling To: Chris Li Cc: Minchan Kim , 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, Zhongkun He Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: okcwuxiedw9t5yupzhqwwkz1u7n55bnm X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 544D140012 X-HE-Tag: 1703067757-643057 X-HE-Meta: U2FsdGVkX19YzpW+1N1/KSK0iP3paZButZ9clEPf2LDUNJXQ2RfDq9iGhRDyIEXNKlG9ebbXel5elexWnrUh6ZDFEmM2u9zPhMRxfvZQXgL0QyDyYwWMjt0Q8BuSn8bsTTz2olGM37QaoOLaUhadJaZVijPA1gPf9+FbFGXK1geUOtQhAQl0dZbYQFpayIhe6bgjeOkAsRFZ7n+y0GoZ8Qmor6mt3ChJvyIa/Sykg3mXkvJsDS1Xl/yp//DhYz6dX1iivvhbsKRRafKvH3K0Ur3lGYkg99XTOYLHKbDoxZ4KD5B3Jjxm3Zu6x6o784gnASaq5N9QO2sUOCR3PTkJzcpenJ2OX2AVaNRU3DbPP7PhK1RlWOKybsc619SJF8Uokq39Uv3++jddIt7AuvRrfwVNAbTbWjeR01WgqKOUxFKA5ZpRl+gJo/s5OHZD7iKvhfl+35/g4VWviN1bI/DyzEYdZdUXjQhVhfWTzJrFSlqHI8IHbgz7bRGXet8qw2XsYl7U9K9w0f+sBUZbv9ptZ5mGFocDX7LRVnqLawetBHt4P3hQ1HPtUYGpTvHktQ4Ef3Rauw942bcfY+gUNQ01ucufyovzd+M42OMBS8C3YqeOpzSl0O0KXJ1QOX/0EqJPFj4McWcrPUFdxTQHr+fbP/xgxY8ooi0PoxvSyAlfw3tTUAMsL7PB8t28oF+do09PcNUSQTNrqqBsv42VNZ588Wq2esz9FVwPpqSbU/wpyR/9U0nPp3lhD9AboChTSJWuEttFxv4bjC8X30AWyJ1fl75kNq1lpxKa3EahbBh0GMHsKwsqUBFyKCii3banJ0pXJif3ht7AoedqLTrdh/0OGg9/8RwQnVBSsCbY8/UWOdJ/kOHPBcZi4N6bxnKrPnl1Rq3sJhQzn+uh1tW9w86IGlM8yI0AIVavvOw5C6VKD3TQM21b9W1N9oXq5BcH+fGm3K1CGi/PMkj3Qnn01CU GdkoHqhw rMu+yVsXShM+f7/pLptUpgdQAPr5Cab/OivasyIt+7wS12a86daDP2aeUCbk3JeiIeWsWVabiuy3KUZbEs6e1KyMYsCqpJFIe9hZH+aC73rHFl7Q1y6KkO1a4zDe429owNjFp3I3br/tTwYDiBTG/6ms6OPfP9lrD8ixLqu4qJkwb3Sp3OdPE+cYLcxX7qp6cdNX2DYrDH6Tv5psmQ1KSi/w/zZGVHzNdJRgH+4c8DDoeQGdkRvi55CfYAJ7FsG/qWcQhiZk8tlsvQTZhVKTatjSOxCl75kO2e3oh2Gn2eCyOMHuKYsK3qXVsaq2gHj+vAcQCWzZAmFW1iXBYuj1jduF0AlDWRVQoljEEHVzcKHp6TL5OYceXMb+c/v4+xISPnyspbkLGpnJDz3YlLehyjJ8TNdjILZp1ymQO 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: Chris Li =E4=BA=8E2023=E5=B9=B412=E6=9C=8813=E6=97=A5= =E5=91=A8=E4=B8=89 07:58=E5=86=99=E9=81=93=EF=BC=9A > > Hi Minchan, > > On Mon, Dec 11, 2023 at 2:55=E2=80=AFPM Minchan Kim = wrote: > > > > > 3) Android has some fancy swap ideas led by those patches. > > > > https://lore.kernel.org/linux-mm/20230710221659.2473460-1-minchan@k= ernel.org/ > > > > It got shot down due to removal of frontswap. But the usage case an= d > > > > product requirement is there. > > > > +Minchan > > > > > > This looks like an optimization for zram to bypass the block layer an= d > > > 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 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. > > 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 is very similar to our usage, easy to implement too. Actually, now ZRAM already supports multiple compression streams, so if each memcg just provides an extra knob to record the compression level (1-4), ZRAM can decide which compression stream to use when the page reaches ZRAM, just by checking pages memcg. It's limited to 4 levels but enough for most cases.