linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Chris Li <chrisl@kernel.org>
To: Minchan Kim <minchan@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Nhat Pham <nphamcs@gmail.com>,
	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 <kasong@tencent.com>,
	 Zhongkun He <hezhongkun.hzk@bytedance.com>
Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling
Date: Tue, 12 Dec 2023 15:57:51 -0800	[thread overview]
Message-ID: <CAF8kJuNzFcBRW=2CbgG=seA=CNgyzD8DNXNY02uy0HUsLbg9JQ@mail.gmail.com> (raw)
In-Reply-To: <ZXeTb_ACou7TEVsa@google.com>

Hi Minchan,

On Mon, Dec 11, 2023 at 2:55 PM Minchan Kim <minchan@kernel.org> wrote:

> > > 3) Android has some fancy swap ideas led by those patches.
> > > https://lore.kernel.org/linux-mm/20230710221659.2473460-1-minchan@kernel.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 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 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, could benefit
> from a slower compression setting that achieves a higher compression ratio.
> 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 swap usage
> within different cgroups.
>

That is again very wonderful insight.

Thanks

Chris


  parent reply	other threads:[~2023-12-12 23:58 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 19:24 Nhat Pham
2023-12-07 19:26 ` Yosry Ahmed
2023-12-07 22:11 ` Andrew Morton
2023-12-08  0:42   ` Nhat Pham
2023-12-08  1:14     ` Nhat Pham
2023-12-08 19:58       ` Andrew Morton
2023-12-08 19:57     ` Andrew Morton
2023-12-08  0:19 ` Chris Li
2023-12-08  1:03   ` Nhat Pham
2023-12-08  1:12     ` Yosry Ahmed
2023-12-08 16:34       ` Johannes Weiner
2023-12-08 20:08         ` Yosry Ahmed
2023-12-09  2:02         ` Chris Li
2023-12-09  0:09       ` Chris Li
2023-12-08 23:55     ` Chris Li
2023-12-09  3:42       ` Johannes Weiner
2023-12-09 17:39         ` Chris Li
2023-12-11 22:55         ` Minchan Kim
2023-12-12  2:43           ` [External] " Zhongkun He
2023-12-12 23:57           ` Chris Li [this message]
2023-12-20 10:22             ` Kairui Song
2023-12-14 17:11           ` Johannes Weiner
2023-12-14 17:23             ` Yu Zhao
2023-12-14 18:00               ` Fabian Deutsch
2023-12-14 23:22                 ` Chris Li
2023-12-15  7:42                   ` Fabian Deutsch
2023-12-15  9:40                     ` Chris Li
2023-12-15  9:50                       ` Fabian Deutsch
2023-12-15  9:18                   ` Fabian Deutsch
2023-12-14 18:03               ` Fabian Deutsch
2023-12-14 17:34             ` Christopher Li
2023-12-14 22:11               ` Johannes Weiner
2023-12-14 22:54                 ` Chris Li
2023-12-15  2:19                   ` Nhat Pham
2023-12-12 21:36         ` Nhat Pham
2023-12-13  0:29           ` Chris Li
2023-12-11  9:31       ` Kairui Song
2023-12-12 23:39         ` Chris Li
2023-12-20 10:21           ` Kairui Song
2023-12-15 21:21 ` Yosry Ahmed
2023-12-18 14:44   ` Johannes Weiner
2023-12-18 19:21     ` Nhat Pham
2023-12-18 21:54       ` Yosry Ahmed
2023-12-18 21:52     ` Yosry Ahmed
2023-12-20  5:15       ` Johannes Weiner
2023-12-20  8:59         ` Yosry Ahmed
2023-12-20 14:50           ` Johannes Weiner
2023-12-21  0:24             ` Yosry Ahmed
2023-12-21  0:50               ` Nhat Pham
2023-12-21  0:57 ` [PATCH v6] zswap: memcontrol: implement zswap writeback disabling (fix) Nhat Pham
2023-12-24 17:17   ` Chris Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF8kJuNzFcBRW=2CbgG=seA=CNgyzD8DNXNY02uy0HUsLbg9JQ@mail.gmail.com' \
    --to=chrisl@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cerasuolodomenico@gmail.com \
    --cc=corbet@lwn.net \
    --cc=david@ixit.cz \
    --cc=ddstreet@ieee.org \
    --cc=hannes@cmpxchg.org \
    --cc=hezhongkun.hzk@bytedance.com \
    --cc=hughd@google.com \
    --cc=kasong@tencent.com \
    --cc=kernel-team@meta.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizefan.x@bytedance.com \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=nphamcs@gmail.com \
    --cc=roman.gushchin@linux.dev \
    --cc=rppt@kernel.org \
    --cc=senozhatsky@chromium.org \
    --cc=shakeelb@google.com \
    --cc=sjenning@redhat.com \
    --cc=tj@kernel.org \
    --cc=vitaly.wool@konsulko.com \
    --cc=yosryahmed@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox