From: Yosry Ahmed <yosryahmed@google.com>
To: Nhat Pham <nphamcs@gmail.com>
Cc: Chris Li <chrisl@kernel.org>,
akpm@linux-foundation.org, tj@kernel.org,
lizefan.x@bytedance.com, hannes@cmpxchg.org,
cerasuolodomenico@gmail.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
Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling
Date: Thu, 7 Dec 2023 17:12:13 -0800 [thread overview]
Message-ID: <CAJD7tkaHaji=0sVobJKajc4hOmOui2U+bZK+1DQ6gbAsQgGLRw@mail.gmail.com> (raw)
In-Reply-To: <CAKEwX=Oj0Rur8i9Oo7y2Py7svx-g11sEj3GKQfMVL62x=4hvdA@mail.gmail.com>
On Thu, Dec 7, 2023 at 5:03 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Thu, Dec 7, 2023 at 4:19 PM Chris Li <chrisl@kernel.org> wrote:
> >
> > Hi Nhat,
> >
> >
> > On Thu, Dec 7, 2023 at 11:24 AM Nhat Pham <nphamcs@gmail.com> wrote:
> > >
> > > During our experiment with zswap, we sometimes observe swap IOs due to
> > > occasional zswap store failures and writebacks-to-swap. These swapping
> > > IOs prevent many users who cannot tolerate swapping from adopting zswap
> > > to save memory and improve performance where possible.
> > >
> > > This patch adds the option to disable this behavior entirely: do not
> > > writeback to backing swapping device when a zswap store attempt fail,
> > > and do not write pages in the zswap pool back to the backing swap
> > > device (both when the pool is full, and when the new zswap shrinker is
> > > called).
> > >
> > > This new behavior can be opted-in/out on a per-cgroup basis via a new
> > > cgroup file. By default, writebacks to swap device is enabled, which is
> > > the previous behavior. Initially, writeback is enabled for the root
> > > cgroup, and a newly created cgroup will inherit the current setting of
> > > its parent.
> > >
> > > Note that this is subtly different from setting memory.swap.max to 0, as
> > > it still allows for pages to be stored in the zswap pool (which itself
> > > consumes swap space in its current form).
> > >
> > > This patch should be applied on top of the zswap shrinker series:
> > >
> > > https://lore.kernel.org/linux-mm/20231130194023.4102148-1-nphamcs@gmail.com/
> > >
> > > as it also disables the zswap shrinker, a major source of zswap
> > > writebacks.
> >
> > I am wondering about the status of "memory.swap.tiers" proof of concept patch?
> > Are we still on board to have this two patch merge together somehow so
> > we can have
> > "memory.swap.tiers" == "all" and "memory.swap.tiers" == "zswap" cover the
> > memory.zswap.writeback == 1 and memory.zswap.writeback == 0 case?
> >
> > Thanks
> >
> > Chris
> >
>
> Hi Chris,
>
> I briefly summarized my recent discussion with Johannes here:
>
> https://lore.kernel.org/all/CAKEwX=NwGGRAtXoNPfq63YnNLBCF0ZDOdLVRsvzUmYhK4jxzHA@mail.gmail.com/
>
> TL;DR is we acknowledge the potential usefulness of swap.tiers
> interface, but the use case is not quite there yet, so it does not
> make too much sense to build up that heavy machinery now.
> zswap.writeback is a more urgent need, and does not prevent swap.tiers
> if we do decide to implement it.
I am honestly not convinced by this. There is no heavy machinery here.
The interface is more generic and extensible, but the implementation
is roughly the same. Unless we have a reason to think a swap.tiers
interface may make it difficult to extend this later or will not
support some use cases, I think we should go ahead with it. If we are
worried that "tiers" may not accurately describe future use cases, we
can be more generic and call it swap.types or something.
next prev parent reply other threads:[~2023-12-08 1:12 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 [this message]
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
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='CAJD7tkaHaji=0sVobJKajc4hOmOui2U+bZK+1DQ6gbAsQgGLRw@mail.gmail.com' \
--to=yosryahmed@google.com \
--cc=akpm@linux-foundation.org \
--cc=cerasuolodomenico@gmail.com \
--cc=chrisl@kernel.org \
--cc=corbet@lwn.net \
--cc=david@ixit.cz \
--cc=ddstreet@ieee.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.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=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 \
/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