* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-12 19:31 [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED Yosry Ahmed
@ 2024-01-12 19:42 ` Nhat Pham
2024-01-12 23:37 ` Yosry Ahmed
2024-01-12 20:13 ` Nhat Pham
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: Nhat Pham @ 2024-01-12 19:42 UTC (permalink / raw)
To: Yosry Ahmed
Cc: Andrew Morton, Vitaly Wool, Miaohe Lin, Johannes Weiner,
Huacai Chen, WANG Xuerui, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Aneesh Kumar K.V, Naveen N. Rao, linux-mm,
loongarch, linuxppc-dev
On Fri, Jan 12, 2024 at 11:31 AM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> The z3fold compressed pages allocator is not widely used, most users use
> zsmalloc. The only disadvantage of zsmalloc in comparison is the
> dependency on MMU, and zbud is a more common option for !MMU as it was
> the default zswap allocator for a long time.
Johannes and I were chatting about this the other day. We might be
able to disable certain zsmalloc behavior in the case of !MMU, making
it available there too. Once that's happened, we can outright remove
z3fold and zbud, and have one allocator to rule them all? :)
>
> In hopes of having a single compressed pages allocator at some point,
> and following in the footsteps of SLAB, deprecate z3fold. Rename the
> user-visible option so that users with CONFIG_Z3FOLD=y get a new prompt
> with explanation during make oldconfig. Remove CONFIG_Z3FOLD=y from
> defconfigs.
>
> Existing users, if any, should voice their objections. Otherwise, we can
> remove z3fold in a few releases.
>
> Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> ---
> I have limited understanding of Kconfigs. I modelled this after commit
> eb07c4f39c3e ("mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED"),
> but one difference is that CONFIG_Z3FOLD is a tristate. I made
> CONFIG_Z3FOLD_DEPRECATED a boolean config, and CONFIG_Z3FOLD default y
> so that it is on by default if CONFIG_Z3FOLD_DEPRECATED is selected. I
> am not sure if that's the correct way to do this.
>
> ---
> arch/loongarch/configs/loongson3_defconfig | 1 -
> arch/powerpc/configs/ppc64_defconfig | 1 -
> mm/Kconfig | 13 +++++++++++--
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/loongarch/configs/loongson3_defconfig b/arch/loongarch/configs/loongson3_defconfig
> index 33795e4a5bd63..89b66b6c6a1d5 100644
> --- a/arch/loongarch/configs/loongson3_defconfig
> +++ b/arch/loongarch/configs/loongson3_defconfig
> @@ -85,7 +85,6 @@ CONFIG_ZPOOL=y
> CONFIG_ZSWAP=y
> CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
> CONFIG_ZBUD=y
> -CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=m
> # CONFIG_COMPAT_BRK is not set
> CONFIG_MEMORY_HOTPLUG=y
> diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
> index 544a65fda77bc..d39284489aa26 100644
> --- a/arch/powerpc/configs/ppc64_defconfig
> +++ b/arch/powerpc/configs/ppc64_defconfig
> @@ -81,7 +81,6 @@ CONFIG_MODULE_SIG_SHA512=y
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_BINFMT_MISC=m
> CONFIG_ZSWAP=y
> -CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=y
> # CONFIG_SLAB_MERGE_DEFAULT is not set
> CONFIG_SLAB_FREELIST_RANDOM=y
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 1902cfe4cc4f5..bc6cc97c08349 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -193,15 +193,24 @@ config ZBUD
> deterministic reclaim properties that make it preferable to a higher
> density approach when reclaim will be used.
>
> -config Z3FOLD
> - tristate "3:1 compression allocator (z3fold)"
> +config Z3FOLD_DEPRECATED
> + bool "3:1 compression allocator (z3fold) (DEPRECATED)"
> depends on ZSWAP
> help
> + Deprecated and scheduled for removal in a few cycles. If you have
> + a good reason for using Z3FOLD rather than ZSMALLOC or ZBUD, please
> + contact linux-mm@kvack.org and the zswap maintainers.
> +
> A special purpose allocator for storing compressed pages.
> It is designed to store up to three compressed pages per physical
> page. It is a ZBUD derivative so the simplicity and determinism are
> still there.
>
> +config Z3FOLD
> + tristate
> + default y
> + depends on Z3FOLD_DEPRECATED
> +
> config ZSMALLOC
> tristate
> prompt "N:1 compression allocator (zsmalloc)" if ZSWAP
> --
> 2.43.0.275.g3460e3d667-goog
>
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-12 19:42 ` Nhat Pham
@ 2024-01-12 23:37 ` Yosry Ahmed
2024-01-13 0:38 ` Nhat Pham
0 siblings, 1 reply; 19+ messages in thread
From: Yosry Ahmed @ 2024-01-12 23:37 UTC (permalink / raw)
To: Nhat Pham
Cc: Andrew Morton, Vitaly Wool, Miaohe Lin, Johannes Weiner,
Huacai Chen, WANG Xuerui, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Aneesh Kumar K.V, Naveen N. Rao, linux-mm,
loongarch, linuxppc-dev, Sergey Senozhatsky, Minchan Kim
On Fri, Jan 12, 2024 at 11:42 AM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Fri, Jan 12, 2024 at 11:31 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > The z3fold compressed pages allocator is not widely used, most users use
> > zsmalloc. The only disadvantage of zsmalloc in comparison is the
> > dependency on MMU, and zbud is a more common option for !MMU as it was
> > the default zswap allocator for a long time.
>
> Johannes and I were chatting about this the other day. We might be
> able to disable certain zsmalloc behavior in the case of !MMU, making
> it available there too. Once that's happened, we can outright remove
> z3fold and zbud, and have one allocator to rule them all? :)
(Adding Sergey and Minchan for visibility)
I didn't want to bring up the zsmalloc MMU dependency in this thread
to reduce noise, but that's also what I had in mind. Sergey and I were
also chatting about this the other day :)
I thought deprecating z3fold is the low hanging fruit. Then, once we
can sort out the MMU dependency in zsmalloc, we can go after zbud as
well.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-12 23:37 ` Yosry Ahmed
@ 2024-01-13 0:38 ` Nhat Pham
2024-01-14 18:49 ` Yosry Ahmed
2024-01-16 15:38 ` Christoph Hellwig
0 siblings, 2 replies; 19+ messages in thread
From: Nhat Pham @ 2024-01-13 0:38 UTC (permalink / raw)
To: Yosry Ahmed
Cc: Andrew Morton, Vitaly Wool, Miaohe Lin, Johannes Weiner,
Huacai Chen, WANG Xuerui, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Aneesh Kumar K.V, Naveen N. Rao, linux-mm,
loongarch, linuxppc-dev, Sergey Senozhatsky, Minchan Kim
On Fri, Jan 12, 2024 at 3:37 PM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> On Fri, Jan 12, 2024 at 11:42 AM Nhat Pham <nphamcs@gmail.com> wrote:
> >
> > On Fri, Jan 12, 2024 at 11:31 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> > >
> > > The z3fold compressed pages allocator is not widely used, most users use
> > > zsmalloc. The only disadvantage of zsmalloc in comparison is the
> > > dependency on MMU, and zbud is a more common option for !MMU as it was
> > > the default zswap allocator for a long time.
> >
> > Johannes and I were chatting about this the other day. We might be
> > able to disable certain zsmalloc behavior in the case of !MMU, making
> > it available there too. Once that's happened, we can outright remove
> > z3fold and zbud, and have one allocator to rule them all? :)
>
> (Adding Sergey and Minchan for visibility)
>
> I didn't want to bring up the zsmalloc MMU dependency in this thread
> to reduce noise, but that's also what I had in mind. Sergey and I were
> also chatting about this the other day :)
>
> I thought deprecating z3fold is the low hanging fruit. Then, once we
> can sort out the MMU dependency in zsmalloc, we can go after zbud as
> well.
Makes sense to me. Should we do the same thing to zbud? We probably
have even less of a case for it, no?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-13 0:38 ` Nhat Pham
@ 2024-01-14 18:49 ` Yosry Ahmed
2024-01-14 22:42 ` Nhat Pham
2024-01-16 15:38 ` Christoph Hellwig
1 sibling, 1 reply; 19+ messages in thread
From: Yosry Ahmed @ 2024-01-14 18:49 UTC (permalink / raw)
To: Nhat Pham
Cc: Andrew Morton, Vitaly Wool, Miaohe Lin, Johannes Weiner,
Huacai Chen, WANG Xuerui, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Aneesh Kumar K.V, Naveen N. Rao, linux-mm,
loongarch, linuxppc-dev, Sergey Senozhatsky, Minchan Kim
On Fri, Jan 12, 2024 at 4:38 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Fri, Jan 12, 2024 at 3:37 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > On Fri, Jan 12, 2024 at 11:42 AM Nhat Pham <nphamcs@gmail.com> wrote:
> > >
> > > On Fri, Jan 12, 2024 at 11:31 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> > > >
> > > > The z3fold compressed pages allocator is not widely used, most users use
> > > > zsmalloc. The only disadvantage of zsmalloc in comparison is the
> > > > dependency on MMU, and zbud is a more common option for !MMU as it was
> > > > the default zswap allocator for a long time.
> > >
> > > Johannes and I were chatting about this the other day. We might be
> > > able to disable certain zsmalloc behavior in the case of !MMU, making
> > > it available there too. Once that's happened, we can outright remove
> > > z3fold and zbud, and have one allocator to rule them all? :)
> >
> > (Adding Sergey and Minchan for visibility)
> >
> > I didn't want to bring up the zsmalloc MMU dependency in this thread
> > to reduce noise, but that's also what I had in mind. Sergey and I were
> > also chatting about this the other day :)
> >
> > I thought deprecating z3fold is the low hanging fruit. Then, once we
> > can sort out the MMU dependency in zsmalloc, we can go after zbud as
> > well.
>
> Makes sense to me. Should we do the same thing to zbud? We probably
> have even less of a case for it, no?
Do you mean declare it as deprecated now? I initially thought that
would only be appropriate to do after zsmalloc has no dependency on
MMU, so that we can confidently say zbud has no practical use case.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-14 18:49 ` Yosry Ahmed
@ 2024-01-14 22:42 ` Nhat Pham
2024-01-14 23:14 ` Yosry Ahmed
0 siblings, 1 reply; 19+ messages in thread
From: Nhat Pham @ 2024-01-14 22:42 UTC (permalink / raw)
To: Yosry Ahmed
Cc: Andrew Morton, Vitaly Wool, Miaohe Lin, Johannes Weiner,
Huacai Chen, WANG Xuerui, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Aneesh Kumar K.V, Naveen N. Rao, linux-mm,
loongarch, linuxppc-dev, Sergey Senozhatsky, Minchan Kim
On Sun, Jan 14, 2024 at 10:49 AM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> On Fri, Jan 12, 2024 at 4:38 PM Nhat Pham <nphamcs@gmail.com> wrote:
> >
> > On Fri, Jan 12, 2024 at 3:37 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> > >
> > > On Fri, Jan 12, 2024 at 11:42 AM Nhat Pham <nphamcs@gmail.com> wrote:
> > > >
> > > > On Fri, Jan 12, 2024 at 11:31 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> > > > >
> > > > > The z3fold compressed pages allocator is not widely used, most users use
> > > > > zsmalloc. The only disadvantage of zsmalloc in comparison is the
> > > > > dependency on MMU, and zbud is a more common option for !MMU as it was
> > > > > the default zswap allocator for a long time.
> > > >
> > > > Johannes and I were chatting about this the other day. We might be
> > > > able to disable certain zsmalloc behavior in the case of !MMU, making
> > > > it available there too. Once that's happened, we can outright remove
> > > > z3fold and zbud, and have one allocator to rule them all? :)
> > >
> > > (Adding Sergey and Minchan for visibility)
> > >
> > > I didn't want to bring up the zsmalloc MMU dependency in this thread
> > > to reduce noise, but that's also what I had in mind. Sergey and I were
> > > also chatting about this the other day :)
> > >
> > > I thought deprecating z3fold is the low hanging fruit. Then, once we
> > > can sort out the MMU dependency in zsmalloc, we can go after zbud as
> > > well.
> >
> > Makes sense to me. Should we do the same thing to zbud? We probably
> > have even less of a case for it, no?
>
> Do you mean declare it as deprecated now? I initially thought that
> would only be appropriate to do after zsmalloc has no dependency on
> MMU, so that we can confidently say zbud has no practical use case.
Ah, I misread your email. My bad. Personally, I'd like to declare both
(zbud and z3fold) as deprecated. That said, no strong feelings here -
as long as (eventually) we move towards retiring both of them. So my
original ACK still holds.
Not entirely sure which should we remove first between zbud and z3fold
though. I was under the assumption that z3fold is slightly better, but
that could be my bias for shiny new things showing :)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-14 22:42 ` Nhat Pham
@ 2024-01-14 23:14 ` Yosry Ahmed
0 siblings, 0 replies; 19+ messages in thread
From: Yosry Ahmed @ 2024-01-14 23:14 UTC (permalink / raw)
To: Nhat Pham
Cc: Andrew Morton, Vitaly Wool, Miaohe Lin, Johannes Weiner,
Huacai Chen, WANG Xuerui, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Aneesh Kumar K.V, Naveen N. Rao, linux-mm,
loongarch, linuxppc-dev, Sergey Senozhatsky, Minchan Kim
On Sun, Jan 14, 2024 at 2:42 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Sun, Jan 14, 2024 at 10:49 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > On Fri, Jan 12, 2024 at 4:38 PM Nhat Pham <nphamcs@gmail.com> wrote:
> > >
> > > On Fri, Jan 12, 2024 at 3:37 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> > > >
> > > > On Fri, Jan 12, 2024 at 11:42 AM Nhat Pham <nphamcs@gmail.com> wrote:
> > > > >
> > > > > On Fri, Jan 12, 2024 at 11:31 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> > > > > >
> > > > > > The z3fold compressed pages allocator is not widely used, most users use
> > > > > > zsmalloc. The only disadvantage of zsmalloc in comparison is the
> > > > > > dependency on MMU, and zbud is a more common option for !MMU as it was
> > > > > > the default zswap allocator for a long time.
> > > > >
> > > > > Johannes and I were chatting about this the other day. We might be
> > > > > able to disable certain zsmalloc behavior in the case of !MMU, making
> > > > > it available there too. Once that's happened, we can outright remove
> > > > > z3fold and zbud, and have one allocator to rule them all? :)
> > > >
> > > > (Adding Sergey and Minchan for visibility)
> > > >
> > > > I didn't want to bring up the zsmalloc MMU dependency in this thread
> > > > to reduce noise, but that's also what I had in mind. Sergey and I were
> > > > also chatting about this the other day :)
> > > >
> > > > I thought deprecating z3fold is the low hanging fruit. Then, once we
> > > > can sort out the MMU dependency in zsmalloc, we can go after zbud as
> > > > well.
> > >
> > > Makes sense to me. Should we do the same thing to zbud? We probably
> > > have even less of a case for it, no?
> >
> > Do you mean declare it as deprecated now? I initially thought that
> > would only be appropriate to do after zsmalloc has no dependency on
> > MMU, so that we can confidently say zbud has no practical use case.
>
> Ah, I misread your email. My bad. Personally, I'd like to declare both
> (zbud and z3fold) as deprecated. That said, no strong feelings here -
> as long as (eventually) we move towards retiring both of them. So my
> original ACK still holds.
>
> Not entirely sure which should we remove first between zbud and z3fold
> though. I was under the assumption that z3fold is slightly better, but
> that could be my bias for shiny new things showing :)
My rationale is that zbud was the default zswap allocator for a long
time, so it's the one we should keep for now as it is more likely to
have users. That said, I don't know of any users of either zbud or
z3fold, and I am fine starting with deprecating either.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-13 0:38 ` Nhat Pham
2024-01-14 18:49 ` Yosry Ahmed
@ 2024-01-16 15:38 ` Christoph Hellwig
2024-01-16 20:19 ` Yosry Ahmed
1 sibling, 1 reply; 19+ messages in thread
From: Christoph Hellwig @ 2024-01-16 15:38 UTC (permalink / raw)
To: Nhat Pham
Cc: Yosry Ahmed, Miaohe Lin, Sergey Senozhatsky, Huacai Chen,
Nicholas Piggin, Aneesh Kumar K.V, linux-mm, loongarch,
Johannes Weiner, Naveen N. Rao, Minchan Kim, Andrew Morton,
linuxppc-dev, WANG Xuerui, Vitaly Wool
On Fri, Jan 12, 2024 at 04:38:30PM -0800, Nhat Pham wrote:
> >
> > I thought deprecating z3fold is the low hanging fruit. Then, once we
> > can sort out the MMU dependency in zsmalloc, we can go after zbud as
> > well.
>
> Makes sense to me. Should we do the same thing to zbud? We probably
> have even less of a case for it, no?
Is there any user visible effect of switching the allocator? If not it
seems a bit pointless to deprecate them vs just removing them (or maybe
making z3fold depend on !MMU for now).
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-16 15:38 ` Christoph Hellwig
@ 2024-01-16 20:19 ` Yosry Ahmed
2024-01-22 7:42 ` Christoph Hellwig
0 siblings, 1 reply; 19+ messages in thread
From: Yosry Ahmed @ 2024-01-16 20:19 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Nhat Pham, Miaohe Lin, Sergey Senozhatsky, Huacai Chen,
Nicholas Piggin, Aneesh Kumar K.V, linux-mm, loongarch,
Johannes Weiner, Naveen N. Rao, Minchan Kim, Andrew Morton,
linuxppc-dev, WANG Xuerui, Vitaly Wool, Chris Li
On Tue, Jan 16, 2024 at 7:39 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Fri, Jan 12, 2024 at 04:38:30PM -0800, Nhat Pham wrote:
> > >
> > > I thought deprecating z3fold is the low hanging fruit. Then, once we
> > > can sort out the MMU dependency in zsmalloc, we can go after zbud as
> > > well.
> >
> > Makes sense to me. Should we do the same thing to zbud? We probably
> > have even less of a case for it, no?
>
> Is there any user visible effect of switching the allocator? If not it
> seems a bit pointless to deprecate them vs just removing them (or maybe
> making z3fold depend on !MMU for now).
Well, better compression ratios for one :)
I think a long time ago there were complaints that zsmalloc had higher
latency than zbud/z3fold, but since then a lot of things have changed
(including nice compaction optimization from Sergey, and compaction
was one of the main factors AFAICT). Also, recent experiments that
Chris Li conducted showed that (at least in our setup), the
decompression is only a small part of the fault latency with zswap
(i.e. not the main factor) -- so I am not sure if it actually matters
in practice.
That said, I have not conducted any experiments personally with z3fold
or zbud, which is why I proposed the conservative approach of marking
as deprecated first. However, if others believe this is unnecessary I
am fine with removal as well. Whatever we agree on is fine by me.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-16 20:19 ` Yosry Ahmed
@ 2024-01-22 7:42 ` Christoph Hellwig
2024-01-22 20:49 ` Yosry Ahmed
0 siblings, 1 reply; 19+ messages in thread
From: Christoph Hellwig @ 2024-01-22 7:42 UTC (permalink / raw)
To: Yosry Ahmed
Cc: Christoph Hellwig, Nhat Pham, Miaohe Lin, Sergey Senozhatsky,
Huacai Chen, Nicholas Piggin, Aneesh Kumar K.V, linux-mm,
loongarch, Johannes Weiner, Naveen N. Rao, Minchan Kim,
Andrew Morton, linuxppc-dev, WANG Xuerui, Vitaly Wool, Chris Li
On Tue, Jan 16, 2024 at 12:19:39PM -0800, Yosry Ahmed wrote:
> Well, better compression ratios for one :)
>
> I think a long time ago there were complaints that zsmalloc had higher
> latency than zbud/z3fold, but since then a lot of things have changed
> (including nice compaction optimization from Sergey, and compaction
> was one of the main factors AFAICT). Also, recent experiments that
> Chris Li conducted showed that (at least in our setup), the
> decompression is only a small part of the fault latency with zswap
> (i.e. not the main factor) -- so I am not sure if it actually matters
> in practice.
>
> That said, I have not conducted any experiments personally with z3fold
> or zbud, which is why I proposed the conservative approach of marking
> as deprecated first. However, if others believe this is unnecessary I
> am fine with removal as well. Whatever we agree on is fine by me.
In general deprecated is for code that has active (intentional) users
and/or would break setups. I does sound to me like that is not the
case here, but others might understand this better.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-22 7:42 ` Christoph Hellwig
@ 2024-01-22 20:49 ` Yosry Ahmed
2024-01-24 21:40 ` Yosry Ahmed
0 siblings, 1 reply; 19+ messages in thread
From: Yosry Ahmed @ 2024-01-22 20:49 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Nhat Pham, Miaohe Lin, Sergey Senozhatsky, Huacai Chen,
Nicholas Piggin, Aneesh Kumar K.V, linux-mm, loongarch,
Johannes Weiner, Naveen N. Rao, Minchan Kim, Andrew Morton,
linuxppc-dev, WANG Xuerui, Vitaly Wool, Chris Li
On Sun, Jan 21, 2024 at 11:42 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Jan 16, 2024 at 12:19:39PM -0800, Yosry Ahmed wrote:
> > Well, better compression ratios for one :)
> >
> > I think a long time ago there were complaints that zsmalloc had higher
> > latency than zbud/z3fold, but since then a lot of things have changed
> > (including nice compaction optimization from Sergey, and compaction
> > was one of the main factors AFAICT). Also, recent experiments that
> > Chris Li conducted showed that (at least in our setup), the
> > decompression is only a small part of the fault latency with zswap
> > (i.e. not the main factor) -- so I am not sure if it actually matters
> > in practice.
> >
> > That said, I have not conducted any experiments personally with z3fold
> > or zbud, which is why I proposed the conservative approach of marking
> > as deprecated first. However, if others believe this is unnecessary I
> > am fine with removal as well. Whatever we agree on is fine by me.
>
> In general deprecated is for code that has active (intentional) users
> and/or would break setups. I does sound to me like that is not the
> case here, but others might understand this better.
I generally agree. So far we have no knowledge of active users, and if
there are some, I expect most of them to be able to switch to zsmalloc
with no problems. That being said, I was trying to take the
conservative approach. If others agree I can send a removal patch
instead.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-22 20:49 ` Yosry Ahmed
@ 2024-01-24 21:40 ` Yosry Ahmed
0 siblings, 0 replies; 19+ messages in thread
From: Yosry Ahmed @ 2024-01-24 21:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, Nhat Pham, Miaohe Lin, Sergey Senozhatsky,
Huacai Chen, Nicholas Piggin, Aneesh Kumar K.V, linux-mm,
loongarch, Johannes Weiner, Naveen N. Rao, Minchan Kim,
linuxppc-dev, WANG Xuerui, Vitaly Wool, Chris Li
On Mon, Jan 22, 2024 at 12:49 PM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> On Sun, Jan 21, 2024 at 11:42 PM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Tue, Jan 16, 2024 at 12:19:39PM -0800, Yosry Ahmed wrote:
> > > Well, better compression ratios for one :)
> > >
> > > I think a long time ago there were complaints that zsmalloc had higher
> > > latency than zbud/z3fold, but since then a lot of things have changed
> > > (including nice compaction optimization from Sergey, and compaction
> > > was one of the main factors AFAICT). Also, recent experiments that
> > > Chris Li conducted showed that (at least in our setup), the
> > > decompression is only a small part of the fault latency with zswap
> > > (i.e. not the main factor) -- so I am not sure if it actually matters
> > > in practice.
> > >
> > > That said, I have not conducted any experiments personally with z3fold
> > > or zbud, which is why I proposed the conservative approach of marking
> > > as deprecated first. However, if others believe this is unnecessary I
> > > am fine with removal as well. Whatever we agree on is fine by me.
> >
> > In general deprecated is for code that has active (intentional) users
> > and/or would break setups. I does sound to me like that is not the
> > case here, but others might understand this better.
>
> I generally agree. So far we have no knowledge of active users, and if
> there are some, I expect most of them to be able to switch to zsmalloc
> with no problems. That being said, I was trying to take the
> conservative approach. If others agree I can send a removal patch
> instead.
Andrew, do you have an opinion here?
We are not sure that there are active users for z3fold. It seems like
we have all sorts of opinions here from "don't deprecate" to "remove
directly, no need to deprecate first".
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-12 19:31 [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED Yosry Ahmed
2024-01-12 19:42 ` Nhat Pham
@ 2024-01-12 20:13 ` Nhat Pham
2024-01-15 12:26 ` Vitaly Wool
2024-01-16 16:44 ` Chris Down
3 siblings, 0 replies; 19+ messages in thread
From: Nhat Pham @ 2024-01-12 20:13 UTC (permalink / raw)
To: Yosry Ahmed
Cc: Andrew Morton, Vitaly Wool, Miaohe Lin, Johannes Weiner,
Huacai Chen, WANG Xuerui, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Aneesh Kumar K.V, Naveen N. Rao, linux-mm,
loongarch, linuxppc-dev
On Fri, Jan 12, 2024 at 11:31 AM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> The z3fold compressed pages allocator is not widely used, most users use
> zsmalloc. The only disadvantage of zsmalloc in comparison is the
> dependency on MMU, and zbud is a more common option for !MMU as it was
> the default zswap allocator for a long time.
>
> In hopes of having a single compressed pages allocator at some point,
> and following in the footsteps of SLAB, deprecate z3fold. Rename the
> user-visible option so that users with CONFIG_Z3FOLD=y get a new prompt
> with explanation during make oldconfig. Remove CONFIG_Z3FOLD=y from
> defconfigs.
>
> Existing users, if any, should voice their objections. Otherwise, we can
> remove z3fold in a few releases.
>
> Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> ---
> I have limited understanding of Kconfigs. I modelled this after commit
> eb07c4f39c3e ("mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED"),
> but one difference is that CONFIG_Z3FOLD is a tristate. I made
> CONFIG_Z3FOLD_DEPRECATED a boolean config, and CONFIG_Z3FOLD default y
> so that it is on by default if CONFIG_Z3FOLD_DEPRECATED is selected. I
> am not sure if that's the correct way to do this.
>
> ---
> arch/loongarch/configs/loongson3_defconfig | 1 -
> arch/powerpc/configs/ppc64_defconfig | 1 -
> mm/Kconfig | 13 +++++++++++--
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/loongarch/configs/loongson3_defconfig b/arch/loongarch/configs/loongson3_defconfig
> index 33795e4a5bd63..89b66b6c6a1d5 100644
> --- a/arch/loongarch/configs/loongson3_defconfig
> +++ b/arch/loongarch/configs/loongson3_defconfig
> @@ -85,7 +85,6 @@ CONFIG_ZPOOL=y
> CONFIG_ZSWAP=y
> CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
> CONFIG_ZBUD=y
> -CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=m
> # CONFIG_COMPAT_BRK is not set
> CONFIG_MEMORY_HOTPLUG=y
> diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
> index 544a65fda77bc..d39284489aa26 100644
> --- a/arch/powerpc/configs/ppc64_defconfig
> +++ b/arch/powerpc/configs/ppc64_defconfig
> @@ -81,7 +81,6 @@ CONFIG_MODULE_SIG_SHA512=y
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_BINFMT_MISC=m
> CONFIG_ZSWAP=y
> -CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=y
> # CONFIG_SLAB_MERGE_DEFAULT is not set
> CONFIG_SLAB_FREELIST_RANDOM=y
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 1902cfe4cc4f5..bc6cc97c08349 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -193,15 +193,24 @@ config ZBUD
> deterministic reclaim properties that make it preferable to a higher
> density approach when reclaim will be used.
>
> -config Z3FOLD
> - tristate "3:1 compression allocator (z3fold)"
> +config Z3FOLD_DEPRECATED
> + bool "3:1 compression allocator (z3fold) (DEPRECATED)"
> depends on ZSWAP
> help
> + Deprecated and scheduled for removal in a few cycles. If you have
> + a good reason for using Z3FOLD rather than ZSMALLOC or ZBUD, please
> + contact linux-mm@kvack.org and the zswap maintainers.
> +
> A special purpose allocator for storing compressed pages.
> It is designed to store up to three compressed pages per physical
> page. It is a ZBUD derivative so the simplicity and determinism are
> still there.
>
> +config Z3FOLD
> + tristate
> + default y
> + depends on Z3FOLD_DEPRECATED
> +
> config ZSMALLOC
> tristate
> prompt "N:1 compression allocator (zsmalloc)" if ZSWAP
> --
> 2.43.0.275.g3460e3d667-goog
>
FWIW:
Acked-by: Nhat Pham <nphamcs@gmail.com>
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-12 19:31 [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED Yosry Ahmed
2024-01-12 19:42 ` Nhat Pham
2024-01-12 20:13 ` Nhat Pham
@ 2024-01-15 12:26 ` Vitaly Wool
2024-01-15 16:47 ` Yosry Ahmed
` (2 more replies)
2024-01-16 16:44 ` Chris Down
3 siblings, 3 replies; 19+ messages in thread
From: Vitaly Wool @ 2024-01-15 12:26 UTC (permalink / raw)
To: Yosry Ahmed
Cc: Andrew Morton, Miaohe Lin, Johannes Weiner, Nhat Pham,
Huacai Chen, WANG Xuerui, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Aneesh Kumar K.V, Naveen N. Rao, linux-mm,
loongarch, linuxppc-dev
On Fri, Jan 12, 2024 at 8:31 PM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> The z3fold compressed pages allocator is not widely used, most users use
> zsmalloc. The only disadvantage of zsmalloc in comparison is the
> dependency on MMU, and zbud is a more common option for !MMU as it was
> the default zswap allocator for a long time.
>
> In hopes of having a single compressed pages allocator at some point,
> and following in the footsteps of SLAB, deprecate z3fold. Rename the
> user-visible option so that users with CONFIG_Z3FOLD=y get a new prompt
> with explanation during make oldconfig. Remove CONFIG_Z3FOLD=y from
> defconfigs.
I believe that having a single compressed pages allocator is a false goal.
> Existing users, if any, should voice their objections. Otherwise, we can
> remove z3fold in a few releases.
At this point I NACK this patch. We're about to submit an allocator
which is clearly better that z3fold and is faster that zsmalloc in
most cases and that submission will mark z3fold as deprecated. But for
now this move is premature.
Best,
Vitaly
> Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> ---
> I have limited understanding of Kconfigs. I modelled this after commit
> eb07c4f39c3e ("mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED"),
> but one difference is that CONFIG_Z3FOLD is a tristate. I made
> CONFIG_Z3FOLD_DEPRECATED a boolean config, and CONFIG_Z3FOLD default y
> so that it is on by default if CONFIG_Z3FOLD_DEPRECATED is selected. I
> am not sure if that's the correct way to do this.
>
> ---
> arch/loongarch/configs/loongson3_defconfig | 1 -
> arch/powerpc/configs/ppc64_defconfig | 1 -
> mm/Kconfig | 13 +++++++++++--
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/loongarch/configs/loongson3_defconfig b/arch/loongarch/configs/loongson3_defconfig
> index 33795e4a5bd63..89b66b6c6a1d5 100644
> --- a/arch/loongarch/configs/loongson3_defconfig
> +++ b/arch/loongarch/configs/loongson3_defconfig
> @@ -85,7 +85,6 @@ CONFIG_ZPOOL=y
> CONFIG_ZSWAP=y
> CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
> CONFIG_ZBUD=y
> -CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=m
> # CONFIG_COMPAT_BRK is not set
> CONFIG_MEMORY_HOTPLUG=y
> diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
> index 544a65fda77bc..d39284489aa26 100644
> --- a/arch/powerpc/configs/ppc64_defconfig
> +++ b/arch/powerpc/configs/ppc64_defconfig
> @@ -81,7 +81,6 @@ CONFIG_MODULE_SIG_SHA512=y
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_BINFMT_MISC=m
> CONFIG_ZSWAP=y
> -CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=y
> # CONFIG_SLAB_MERGE_DEFAULT is not set
> CONFIG_SLAB_FREELIST_RANDOM=y
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 1902cfe4cc4f5..bc6cc97c08349 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -193,15 +193,24 @@ config ZBUD
> deterministic reclaim properties that make it preferable to a higher
> density approach when reclaim will be used.
>
> -config Z3FOLD
> - tristate "3:1 compression allocator (z3fold)"
> +config Z3FOLD_DEPRECATED
> + bool "3:1 compression allocator (z3fold) (DEPRECATED)"
> depends on ZSWAP
> help
> + Deprecated and scheduled for removal in a few cycles. If you have
> + a good reason for using Z3FOLD rather than ZSMALLOC or ZBUD, please
> + contact linux-mm@kvack.org and the zswap maintainers.
> +
> A special purpose allocator for storing compressed pages.
> It is designed to store up to three compressed pages per physical
> page. It is a ZBUD derivative so the simplicity and determinism are
> still there.
>
> +config Z3FOLD
> + tristate
> + default y
> + depends on Z3FOLD_DEPRECATED
> +
> config ZSMALLOC
> tristate
> prompt "N:1 compression allocator (zsmalloc)" if ZSWAP
> --
> 2.43.0.275.g3460e3d667-goog
>
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-15 12:26 ` Vitaly Wool
@ 2024-01-15 16:47 ` Yosry Ahmed
2024-01-16 4:27 ` Sergey Senozhatsky
2024-01-15 20:01 ` Nhat Pham
2024-01-16 16:46 ` Chris Down
2 siblings, 1 reply; 19+ messages in thread
From: Yosry Ahmed @ 2024-01-15 16:47 UTC (permalink / raw)
To: Vitaly Wool
Cc: Andrew Morton, Miaohe Lin, Johannes Weiner, Nhat Pham,
Huacai Chen, WANG Xuerui, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Aneesh Kumar K.V, Naveen N. Rao, linux-mm,
loongarch, linuxppc-dev
On Mon, Jan 15, 2024 at 4:27 AM Vitaly Wool <vitaly.wool@konsulko.com> wrote:
>
> On Fri, Jan 12, 2024 at 8:31 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > The z3fold compressed pages allocator is not widely used, most users use
> > zsmalloc. The only disadvantage of zsmalloc in comparison is the
> > dependency on MMU, and zbud is a more common option for !MMU as it was
> > the default zswap allocator for a long time.
> >
> > In hopes of having a single compressed pages allocator at some point,
> > and following in the footsteps of SLAB, deprecate z3fold. Rename the
> > user-visible option so that users with CONFIG_Z3FOLD=y get a new prompt
> > with explanation during make oldconfig. Remove CONFIG_Z3FOLD=y from
> > defconfigs.
>
> I believe that having a single compressed pages allocator is a false goal.
It's not a goal in itself for sure, but when most users use one
allocator that is mostly superior, it makes sense to try to deprecate
others.
>
> > Existing users, if any, should voice their objections. Otherwise, we can
> > remove z3fold in a few releases.
>
> At this point I NACK this patch. We're about to submit an allocator
> which is clearly better that z3fold and is faster that zsmalloc in
> most cases and that submission will mark z3fold as deprecated. But for
> now this move is premature.
I think unless there are current users of z3fold that cannot use
zsmalloc, the introduction of a new allocator should be irrelevant to
deprecating z3fold. Do you know of such users? Can you explain why
zsmalloc is not usable for them?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-15 16:47 ` Yosry Ahmed
@ 2024-01-16 4:27 ` Sergey Senozhatsky
0 siblings, 0 replies; 19+ messages in thread
From: Sergey Senozhatsky @ 2024-01-16 4:27 UTC (permalink / raw)
To: Vitaly Wool, Yosry Ahmed
Cc: Andrew Morton, Miaohe Lin, Johannes Weiner, Nhat Pham,
Huacai Chen, WANG Xuerui, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Aneesh Kumar K.V, Naveen N. Rao, linux-mm,
loongarch, linuxppc-dev
On (24/01/15 08:47), Yosry Ahmed wrote:
> > At this point I NACK this patch. We're about to submit an allocator
> > which is clearly better that z3fold and is faster that zsmalloc in
> > most cases and that submission will mark z3fold as deprecated. But for
> > now this move is premature.
>
> I think unless there are current users of z3fold that cannot use
> zsmalloc, the introduction of a new allocator should be irrelevant to
> deprecating z3fold. Do you know of such users? Can you explain why
> zsmalloc is not usable for them?
I second this. I believe "do we know whether z3fold has users"
is a legit question that means no offense.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-15 12:26 ` Vitaly Wool
2024-01-15 16:47 ` Yosry Ahmed
@ 2024-01-15 20:01 ` Nhat Pham
2024-01-16 16:46 ` Chris Down
2 siblings, 0 replies; 19+ messages in thread
From: Nhat Pham @ 2024-01-15 20:01 UTC (permalink / raw)
To: Vitaly Wool
Cc: Yosry Ahmed, Andrew Morton, Miaohe Lin, Johannes Weiner,
Huacai Chen, WANG Xuerui, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Aneesh Kumar K.V, Naveen N. Rao, linux-mm,
loongarch, linuxppc-dev
On Mon, Jan 15, 2024 at 4:27 AM Vitaly Wool <vitaly.wool@konsulko.com> wrote:
>
> On Fri, Jan 12, 2024 at 8:31 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > The z3fold compressed pages allocator is not widely used, most users use
> > zsmalloc. The only disadvantage of zsmalloc in comparison is the
> > dependency on MMU, and zbud is a more common option for !MMU as it was
> > the default zswap allocator for a long time.
> >
> > In hopes of having a single compressed pages allocator at some point,
> > and following in the footsteps of SLAB, deprecate z3fold. Rename the
> > user-visible option so that users with CONFIG_Z3FOLD=y get a new prompt
> > with explanation during make oldconfig. Remove CONFIG_Z3FOLD=y from
> > defconfigs.
>
> I believe that having a single compressed pages allocator is a false goal.
I think it should be, where possible. Having fewer code will lower the
maintenance burden. Of course, this is not always possible, as one
option might be the best in one aspect/use case, but not so in others.
In the case of zswap (which is the only user for zbud and z3fold), it
seems (to me anyway) zbud and z3fold aren't really serious competitors
for zsmalloc anymore (outside of that aforementioned !MMU case). I'd
love to hear some use cases if I'm mistaken though :)
>
> > Existing users, if any, should voice their objections. Otherwise, we can
> > remove z3fold in a few releases.
>
> At this point I NACK this patch. We're about to submit an allocator
> which is clearly better that z3fold and is faster that zsmalloc in
> most cases and that submission will mark z3fold as deprecated. But for
> now this move is premature.
Ah, this sounds promising. I'd love to hear more about this new
allocator, and once it's available, experiment with it internally too
:)
That said, even at this point, does anyone actually use z3fold and/or
zbud, and cannot use zsmalloc? If yes, then yeah this is quite
premature. If not, then we can mark them as deprecate, no? Introducing
the other allocator and fixing zsmalloc for !MMU can be done in
parallel - we're not removing z3fold and zbud anytime soon even with
this deprecation notice.
>
> Best,
> Vitaly
>
> > Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> > ---
> > I have limited understanding of Kconfigs. I modelled this after commit
> > eb07c4f39c3e ("mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED"),
> > but one difference is that CONFIG_Z3FOLD is a tristate. I made
> > CONFIG_Z3FOLD_DEPRECATED a boolean config, and CONFIG_Z3FOLD default y
> > so that it is on by default if CONFIG_Z3FOLD_DEPRECATED is selected. I
> > am not sure if that's the correct way to do this.
> >
> > ---
> > arch/loongarch/configs/loongson3_defconfig | 1 -
> > arch/powerpc/configs/ppc64_defconfig | 1 -
> > mm/Kconfig | 13 +++++++++++--
> > 3 files changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/loongarch/configs/loongson3_defconfig b/arch/loongarch/configs/loongson3_defconfig
> > index 33795e4a5bd63..89b66b6c6a1d5 100644
> > --- a/arch/loongarch/configs/loongson3_defconfig
> > +++ b/arch/loongarch/configs/loongson3_defconfig
> > @@ -85,7 +85,6 @@ CONFIG_ZPOOL=y
> > CONFIG_ZSWAP=y
> > CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
> > CONFIG_ZBUD=y
> > -CONFIG_Z3FOLD=y
> > CONFIG_ZSMALLOC=m
> > # CONFIG_COMPAT_BRK is not set
> > CONFIG_MEMORY_HOTPLUG=y
> > diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
> > index 544a65fda77bc..d39284489aa26 100644
> > --- a/arch/powerpc/configs/ppc64_defconfig
> > +++ b/arch/powerpc/configs/ppc64_defconfig
> > @@ -81,7 +81,6 @@ CONFIG_MODULE_SIG_SHA512=y
> > CONFIG_PARTITION_ADVANCED=y
> > CONFIG_BINFMT_MISC=m
> > CONFIG_ZSWAP=y
> > -CONFIG_Z3FOLD=y
> > CONFIG_ZSMALLOC=y
> > # CONFIG_SLAB_MERGE_DEFAULT is not set
> > CONFIG_SLAB_FREELIST_RANDOM=y
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 1902cfe4cc4f5..bc6cc97c08349 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -193,15 +193,24 @@ config ZBUD
> > deterministic reclaim properties that make it preferable to a higher
> > density approach when reclaim will be used.
> >
> > -config Z3FOLD
> > - tristate "3:1 compression allocator (z3fold)"
> > +config Z3FOLD_DEPRECATED
> > + bool "3:1 compression allocator (z3fold) (DEPRECATED)"
> > depends on ZSWAP
> > help
> > + Deprecated and scheduled for removal in a few cycles. If you have
> > + a good reason for using Z3FOLD rather than ZSMALLOC or ZBUD, please
> > + contact linux-mm@kvack.org and the zswap maintainers.
> > +
> > A special purpose allocator for storing compressed pages.
> > It is designed to store up to three compressed pages per physical
> > page. It is a ZBUD derivative so the simplicity and determinism are
> > still there.
> >
> > +config Z3FOLD
> > + tristate
> > + default y
> > + depends on Z3FOLD_DEPRECATED
> > +
> > config ZSMALLOC
> > tristate
> > prompt "N:1 compression allocator (zsmalloc)" if ZSWAP
> > --
> > 2.43.0.275.g3460e3d667-goog
> >
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-15 12:26 ` Vitaly Wool
2024-01-15 16:47 ` Yosry Ahmed
2024-01-15 20:01 ` Nhat Pham
@ 2024-01-16 16:46 ` Chris Down
2 siblings, 0 replies; 19+ messages in thread
From: Chris Down @ 2024-01-16 16:46 UTC (permalink / raw)
To: Vitaly Wool
Cc: Yosry Ahmed, Andrew Morton, Miaohe Lin, Johannes Weiner,
Nhat Pham, Huacai Chen, WANG Xuerui, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Aneesh Kumar K.V,
Naveen N. Rao, linux-mm, loongarch, linuxppc-dev
Vitaly Wool writes:
>> Existing users, if any, should voice their objections. Otherwise, we can
>> remove z3fold in a few releases.
>
>At this point I NACK this patch. We're about to submit an allocator
>which is clearly better that z3fold and is faster that zsmalloc in
>most cases and that submission will mark z3fold as deprecated. But for
>now this move is premature.
Why should that block completely unrelated cleanup work? Let's please not add
dependencies between patches when there don't need to be.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
2024-01-12 19:31 [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED Yosry Ahmed
` (2 preceding siblings ...)
2024-01-15 12:26 ` Vitaly Wool
@ 2024-01-16 16:44 ` Chris Down
3 siblings, 0 replies; 19+ messages in thread
From: Chris Down @ 2024-01-16 16:44 UTC (permalink / raw)
To: Yosry Ahmed
Cc: Andrew Morton, Vitaly Wool, Miaohe Lin, Johannes Weiner,
Nhat Pham, Huacai Chen, WANG Xuerui, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Aneesh Kumar K.V,
Naveen N. Rao, linux-mm, loongarch, linuxppc-dev
Yosry Ahmed writes:
>The z3fold compressed pages allocator is not widely used, most users use
>zsmalloc. The only disadvantage of zsmalloc in comparison is the
>dependency on MMU, and zbud is a more common option for !MMU as it was
>the default zswap allocator for a long time.
>
>In hopes of having a single compressed pages allocator at some point,
>and following in the footsteps of SLAB, deprecate z3fold. Rename the
>user-visible option so that users with CONFIG_Z3FOLD=y get a new prompt
>with explanation during make oldconfig. Remove CONFIG_Z3FOLD=y from
>defconfigs.
>
>Existing users, if any, should voice their objections. Otherwise, we can
>remove z3fold in a few releases.
>
>Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
Acked-by: Chris Down <chris@chrisdown.name>
Thanks. We are definitely hurting users as well by keeping this around with its
known issues when writeback is disabled, for example.
>---
>I have limited understanding of Kconfigs. I modelled this after commit
>eb07c4f39c3e ("mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED"),
>but one difference is that CONFIG_Z3FOLD is a tristate. I made
>CONFIG_Z3FOLD_DEPRECATED a boolean config, and CONFIG_Z3FOLD default y
>so that it is on by default if CONFIG_Z3FOLD_DEPRECATED is selected. I
>am not sure if that's the correct way to do this.
>
>---
> arch/loongarch/configs/loongson3_defconfig | 1 -
> arch/powerpc/configs/ppc64_defconfig | 1 -
> mm/Kconfig | 13 +++++++++++--
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
>diff --git a/arch/loongarch/configs/loongson3_defconfig b/arch/loongarch/configs/loongson3_defconfig
>index 33795e4a5bd63..89b66b6c6a1d5 100644
>--- a/arch/loongarch/configs/loongson3_defconfig
>+++ b/arch/loongarch/configs/loongson3_defconfig
>@@ -85,7 +85,6 @@ CONFIG_ZPOOL=y
> CONFIG_ZSWAP=y
> CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
> CONFIG_ZBUD=y
>-CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=m
> # CONFIG_COMPAT_BRK is not set
> CONFIG_MEMORY_HOTPLUG=y
>diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
>index 544a65fda77bc..d39284489aa26 100644
>--- a/arch/powerpc/configs/ppc64_defconfig
>+++ b/arch/powerpc/configs/ppc64_defconfig
>@@ -81,7 +81,6 @@ CONFIG_MODULE_SIG_SHA512=y
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_BINFMT_MISC=m
> CONFIG_ZSWAP=y
>-CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=y
> # CONFIG_SLAB_MERGE_DEFAULT is not set
> CONFIG_SLAB_FREELIST_RANDOM=y
>diff --git a/mm/Kconfig b/mm/Kconfig
>index 1902cfe4cc4f5..bc6cc97c08349 100644
>--- a/mm/Kconfig
>+++ b/mm/Kconfig
>@@ -193,15 +193,24 @@ config ZBUD
> deterministic reclaim properties that make it preferable to a higher
> density approach when reclaim will be used.
>
>-config Z3FOLD
>- tristate "3:1 compression allocator (z3fold)"
>+config Z3FOLD_DEPRECATED
>+ bool "3:1 compression allocator (z3fold) (DEPRECATED)"
> depends on ZSWAP
> help
>+ Deprecated and scheduled for removal in a few cycles. If you have
>+ a good reason for using Z3FOLD rather than ZSMALLOC or ZBUD, please
>+ contact linux-mm@kvack.org and the zswap maintainers.
>+
> A special purpose allocator for storing compressed pages.
> It is designed to store up to three compressed pages per physical
> page. It is a ZBUD derivative so the simplicity and determinism are
> still there.
>
>+config Z3FOLD
>+ tristate
>+ default y
>+ depends on Z3FOLD_DEPRECATED
>+
> config ZSMALLOC
> tristate
> prompt "N:1 compression allocator (zsmalloc)" if ZSWAP
>--
>2.43.0.275.g3460e3d667-goog
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread