[PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[Yosry Ahmed]

The zbud compressed pages allocator is rarely used, most users use
zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed
pages per physical page). The only advantage of zbud is a marginal
performance improvement that by no means justify the memory overhead.

Historically, zsmalloc had significantly worse latency than zbud and
z3fold but offered better memory savings.  This is no longer the case as
shown by a simple recent analysis [1].  In a kernel build test on tmpfs
in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost
of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make
sense for zbud in any practical scenario.

The only alleged advantage of zbud is not having the dependency on
CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and
zbud is only used by zswap.

Following in the footsteps of [2], which deprecated z3fold, deprecated
zbud as planned and remove it in a few cycles if no objections are
raised from active users.

Rename the user-visible config options so that users with CONFIG_ZBUD=y
get a new prompt with explanation during make oldconfig. Also, remove
CONFIG_ZBUD from defconfig.

[1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/
[2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/

Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
---
 arch/loongarch/configs/loongson3_defconfig |  3 +--
 mm/Kconfig                                 | 26 ++++++++++++++++------
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/arch/loongarch/configs/loongson3_defconfig b/arch/loongarch/configs/loongson3_defconfig
index 73c77500ac467..7ce5beb3cbf34 100644
--- a/arch/loongarch/configs/loongson3_defconfig
+++ b/arch/loongarch/configs/loongson3_defconfig
@@ -109,8 +109,7 @@ CONFIG_BINFMT_MISC=m
 CONFIG_ZPOOL=y
 CONFIG_ZSWAP=y
 CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
-CONFIG_ZBUD=y
-CONFIG_ZSMALLOC=m
+CONFIG_ZSMALLOC=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_MEMORY_HOTPLUG=y
 # CONFIG_MHP_DEFAULT_ONLINE_TYPE_OFFLINE is not set
diff --git a/mm/Kconfig b/mm/Kconfig
index 1b501db064172..e3e15ab0cba49 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -129,7 +129,6 @@ choice
 	prompt "Default allocator"
 	depends on ZSWAP
 	default ZSWAP_ZPOOL_DEFAULT_ZSMALLOC if MMU
-	default ZSWAP_ZPOOL_DEFAULT_ZBUD
 	help
 	  Selects the default allocator for the compressed cache for
 	  swap pages.
@@ -140,12 +139,15 @@ choice
 	  The selection made here can be overridden by using the kernel
 	  command line 'zswap.zpool=' option.
 
-config ZSWAP_ZPOOL_DEFAULT_ZBUD
-	bool "zbud"
-	select ZBUD
+config ZSWAP_ZPOOL_DEFAULT_ZBUD_DEPRECATED
+	bool "zbud (DEPRECATED)"
+	select ZBUD_DEPRECATED
 	help
 	  Use the zbud allocator as the default allocator.
 
+	  Deprecated and scheduled for removal in a few cycles,
+	  see CONFIG_ZBUD_DEPRECATED.
+
 config ZSWAP_ZPOOL_DEFAULT_Z3FOLD_DEPRECATED
 	bool "z3foldi (DEPRECATED)"
 	select Z3FOLD_DEPRECATED
@@ -165,21 +167,31 @@ endchoice
 config ZSWAP_ZPOOL_DEFAULT
        string
        depends on ZSWAP
-       default "zbud" if ZSWAP_ZPOOL_DEFAULT_ZBUD
+       default "zbud" if ZSWAP_ZPOOL_DEFAULT_ZBUD_DEPRECATED
        default "z3fold" if ZSWAP_ZPOOL_DEFAULT_Z3FOLD_DEPRECATED
        default "zsmalloc" if ZSWAP_ZPOOL_DEFAULT_ZSMALLOC
        default ""
 
-config ZBUD
-	tristate "2:1 compression allocator (zbud)"
+config ZBUD_DEPRECATED
+	tristate "2:1 compression allocator (zbud) (DEPRECATED)"
 	depends on ZSWAP
 	help
+	  Deprecated and scheduled for removal in a few cycles. If you have
+	  a good reason for using ZBUD over ZSMALLOC, 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 two compressed pages per physical
 	  page.  While this design limits storage density, it has simple and
 	  deterministic reclaim properties that make it preferable to a higher
 	  density approach when reclaim will be used.
 
+config ZBUD
+	tristate
+	default y if ZBUD_DEPRECATED=y
+	default m if ZBUD_DEPRECATED=m
+	depends on ZBUD_DEPRECATED
+
 config Z3FOLD_DEPRECATED
 	tristate "3:1 compression allocator (z3fold) (DEPRECATED)"
 	depends on ZSWAP
-- 
2.48.1.262.g85cc9f2d1e-goog

Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[Johannes Weiner]

On Mon, Jan 27, 2025 at 11:58:21PM +0000, Yosry Ahmed wrote:
> The zbud compressed pages allocator is rarely used, most users use
> zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed
> pages per physical page). The only advantage of zbud is a marginal
> performance improvement that by no means justify the memory overhead.
> 
> Historically, zsmalloc had significantly worse latency than zbud and
> z3fold but offered better memory savings.  This is no longer the case as
> shown by a simple recent analysis [1].  In a kernel build test on tmpfs
> in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost
> of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make
> sense for zbud in any practical scenario.
> 
> The only alleged advantage of zbud is not having the dependency on
> CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and
> zbud is only used by zswap.
> 
> Following in the footsteps of [2], which deprecated z3fold, deprecated
> zbud as planned and remove it in a few cycles if no objections are
> raised from active users.
> 
> Rename the user-visible config options so that users with CONFIG_ZBUD=y
> get a new prompt with explanation during make oldconfig. Also, remove
> CONFIG_ZBUD from defconfig.
> 
> [1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/
> [2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/
> 
> Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>

Can we just drop it right away?

The two cycles for z3fold were basically in the "not worth bothering"
category, since very few downstream production systems rebase that
frequently.

zsmalloc has been in use on everything from mobile devices to large
servers for years. It's been the default since 6.6 (Oct '23) for
zswap, and the only option for zram from the start.

Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[Vlastimil Babka]

On 1/28/25 00:58, Yosry Ahmed wrote:
> The zbud compressed pages allocator is rarely used, most users use
> zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed
> pages per physical page). The only advantage of zbud is a marginal
> performance improvement that by no means justify the memory overhead.
> 
> Historically, zsmalloc had significantly worse latency than zbud and
> z3fold but offered better memory savings.  This is no longer the case as
> shown by a simple recent analysis [1].  In a kernel build test on tmpfs
> in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost
> of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make
> sense for zbud in any practical scenario.
> 
> The only alleged advantage of zbud is not having the dependency on
> CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and
> zbud is only used by zswap.
> 
> Following in the footsteps of [2], which deprecated z3fold, deprecated
> zbud as planned and remove it in a few cycles if no objections are
> raised from active users.
> 
> Rename the user-visible config options so that users with CONFIG_ZBUD=y
> get a new prompt with explanation during make oldconfig. Also, remove
> CONFIG_ZBUD from defconfig.
> 
> [1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/
> [2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/
> 
> Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>

Seems weird not to Cc the folks listed in MAINTAINERS for ZBUD? Unless their
addresses are known to bounce?
And ZRAM maintainers should also be Ccd?

Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[Vitaly Wool]

[-- Attachment #1: Type: text/plain, Size: 5200 bytes --]

Hi Yosry,

On Tue, Jan 28, 2025 at 12:58 AM Yosry Ahmed <yosry.ahmed@linux.dev> wrote:

> The zbud compressed pages allocator is rarely used, most users use
> zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed
> pages per physical page). The only advantage of zbud is a marginal
> performance improvement that by no means justify the memory overhead.
>
> Historically, zsmalloc had significantly worse latency than zbud and
> z3fold but offered better memory savings.  This is no longer the case as
> shown by a simple recent analysis [1].  In a kernel build test on tmpfs
> in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost
> of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make
> sense for zbud in any practical scenario.
>
> The only alleged advantage of zbud is not having the dependency on
> CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and
> zbud is only used by zswap.
>
> Following in the footsteps of [2], which deprecated z3fold, deprecated
> zbud as planned and remove it in a few cycles if no objections are
> raised from active users.
>
> Rename the user-visible config options so that users with CONFIG_ZBUD=y
> get a new prompt with explanation during make oldconfig. Also, remove
> CONFIG_ZBUD from defconfig.
>
> [1]
> https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/
> [2]
> https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/
>
> Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
>

Let me disagree here. The footprint for zbud and the ability to work in
MMU-less setups make it self sufficient and I don't support its deprecation.
I can give a formal NAK if that's required.

Thanks,
Vitaly


> ---
>  arch/loongarch/configs/loongson3_defconfig |  3 +--
>  mm/Kconfig                                 | 26 ++++++++++++++++------
>  2 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/arch/loongarch/configs/loongson3_defconfig
> b/arch/loongarch/configs/loongson3_defconfig
> index 73c77500ac467..7ce5beb3cbf34 100644
> --- a/arch/loongarch/configs/loongson3_defconfig
> +++ b/arch/loongarch/configs/loongson3_defconfig
> @@ -109,8 +109,7 @@ CONFIG_BINFMT_MISC=m
>  CONFIG_ZPOOL=y
>  CONFIG_ZSWAP=y
>  CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
> -CONFIG_ZBUD=y
> -CONFIG_ZSMALLOC=m
> +CONFIG_ZSMALLOC=y
>  # CONFIG_COMPAT_BRK is not set
>  CONFIG_MEMORY_HOTPLUG=y
>  # CONFIG_MHP_DEFAULT_ONLINE_TYPE_OFFLINE is not set
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 1b501db064172..e3e15ab0cba49 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -129,7 +129,6 @@ choice
>         prompt "Default allocator"
>         depends on ZSWAP
>         default ZSWAP_ZPOOL_DEFAULT_ZSMALLOC if MMU
> -       default ZSWAP_ZPOOL_DEFAULT_ZBUD
>         help
>           Selects the default allocator for the compressed cache for
>           swap pages.
> @@ -140,12 +139,15 @@ choice
>           The selection made here can be overridden by using the kernel
>           command line 'zswap.zpool=' option.
>
> -config ZSWAP_ZPOOL_DEFAULT_ZBUD
> -       bool "zbud"
> -       select ZBUD
> +config ZSWAP_ZPOOL_DEFAULT_ZBUD_DEPRECATED
> +       bool "zbud (DEPRECATED)"
> +       select ZBUD_DEPRECATED
>         help
>           Use the zbud allocator as the default allocator.
>
> +         Deprecated and scheduled for removal in a few cycles,
> +         see CONFIG_ZBUD_DEPRECATED.
> +
>  config ZSWAP_ZPOOL_DEFAULT_Z3FOLD_DEPRECATED
>         bool "z3foldi (DEPRECATED)"
>         select Z3FOLD_DEPRECATED
> @@ -165,21 +167,31 @@ endchoice
>  config ZSWAP_ZPOOL_DEFAULT
>         string
>         depends on ZSWAP
> -       default "zbud" if ZSWAP_ZPOOL_DEFAULT_ZBUD
> +       default "zbud" if ZSWAP_ZPOOL_DEFAULT_ZBUD_DEPRECATED
>         default "z3fold" if ZSWAP_ZPOOL_DEFAULT_Z3FOLD_DEPRECATED
>         default "zsmalloc" if ZSWAP_ZPOOL_DEFAULT_ZSMALLOC
>         default ""
>
> -config ZBUD
> -       tristate "2:1 compression allocator (zbud)"
> +config ZBUD_DEPRECATED
> +       tristate "2:1 compression allocator (zbud) (DEPRECATED)"
>         depends on ZSWAP
>         help
> +         Deprecated and scheduled for removal in a few cycles. If you have
> +         a good reason for using ZBUD over ZSMALLOC, 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 two compressed pages per physical
>           page.  While this design limits storage density, it has simple
> and
>           deterministic reclaim properties that make it preferable to a
> higher
>           density approach when reclaim will be used.
>
> +config ZBUD
> +       tristate
> +       default y if ZBUD_DEPRECATED=y
> +       default m if ZBUD_DEPRECATED=m
> +       depends on ZBUD_DEPRECATED
> +
>  config Z3FOLD_DEPRECATED
>         tristate "3:1 compression allocator (z3fold) (DEPRECATED)"
>         depends on ZSWAP
> --
> 2.48.1.262.g85cc9f2d1e-goog
>
>

[-- Attachment #2: Type: text/html, Size: 6695 bytes --]

Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[Yosry Ahmed]

January 28, 2025 at 2:14 AM, "Johannes Weiner" <hannes@cmpxchg.org> wrote:



> 
> On Mon, Jan 27, 2025 at 11:58:21PM +0000, Yosry Ahmed wrote:
> 
> > 
> > The zbud compressed pages allocator is rarely used, most users use
> > 
> >  zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed
> > 
> >  pages per physical page). The only advantage of zbud is a marginal
> > 
> >  performance improvement that by no means justify the memory overhead.
> > 
> >  
> > 
> >  Historically, zsmalloc had significantly worse latency than zbud and
> > 
> >  z3fold but offered better memory savings. This is no longer the case as
> > 
> >  shown by a simple recent analysis [1]. In a kernel build test on tmpfs
> > 
> >  in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost
> > 
> >  of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make
> > 
> >  sense for zbud in any practical scenario.
> > 
> >  
> > 
> >  The only alleged advantage of zbud is not having the dependency on
> > 
> >  CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and
> > 
> >  zbud is only used by zswap.
> > 
> >  
> > 
> >  Following in the footsteps of [2], which deprecated z3fold, deprecated
> > 
> >  zbud as planned and remove it in a few cycles if no objections are
> > 
> >  raised from active users.
> > 
> >  
> > 
> >  Rename the user-visible config options so that users with CONFIG_ZBUD=y
> > 
> >  get a new prompt with explanation during make oldconfig. Also, remove
> > 
> >  CONFIG_ZBUD from defconfig.
> > 
> >  
> > 
> >  [1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/
> > 
> >  [2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/
> > 
> >  
> > 
> >  Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
> > 
> 
> Can we just drop it right away?
> 
> The two cycles for z3fold were basically in the "not worth bothering"
> 
> category, since very few downstream production systems rebase that
> 
> frequently.
> 
> zsmalloc has been in use on everything from mobile devices to large
> 
> servers for years. It's been the default since 6.6 (Oct '23) for
> 
> zswap, and the only option for zram from the start.

I certainly do not object, if no one else objects I can do that. We can leave the zpool code around for a bit in case a new allocator shows up tho, just as due diligence.

Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[Yosry Ahmed]

On Tue, Jan 28, 2025 at 11:21:10AM +0100, Vlastimil Babka wrote:
> On 1/28/25 00:58, Yosry Ahmed wrote:
> > The zbud compressed pages allocator is rarely used, most users use
> > zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed
> > pages per physical page). The only advantage of zbud is a marginal
> > performance improvement that by no means justify the memory overhead.
> > 
> > Historically, zsmalloc had significantly worse latency than zbud and
> > z3fold but offered better memory savings.  This is no longer the case as
> > shown by a simple recent analysis [1].  In a kernel build test on tmpfs
> > in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost
> > of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make
> > sense for zbud in any practical scenario.
> > 
> > The only alleged advantage of zbud is not having the dependency on
> > CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and
> > zbud is only used by zswap.
> > 
> > Following in the footsteps of [2], which deprecated z3fold, deprecated
> > zbud as planned and remove it in a few cycles if no objections are
> > raised from active users.
> > 
> > Rename the user-visible config options so that users with CONFIG_ZBUD=y
> > get a new prompt with explanation during make oldconfig. Also, remove
> > CONFIG_ZBUD from defconfig.
> > 
> > [1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/
> > [2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/
> > 
> > Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
> 
> Seems weird not to Cc the folks listed in MAINTAINERS for ZBUD? Unless their
> addresses are known to bounce?

Ugh I had them in the CC list, but I played around with it and probably
lost them :/

Seth, Dan, apologies.

> And ZRAM maintainers should also be Ccd?

ZRAM does not use zbud, I can definitely CC them but I don't want to be
a source of noise :)

Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[Yosry Ahmed]

On Tue, Jan 28, 2025 at 11:29:07AM +0100, Vitaly Wool wrote:
> Hi Yosry,
> 
> On Tue, Jan 28, 2025 at 12:58 AM Yosry Ahmed <yosry.ahmed@linux.dev> wrote:
> 
> > The zbud compressed pages allocator is rarely used, most users use
> > zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed
> > pages per physical page). The only advantage of zbud is a marginal
> > performance improvement that by no means justify the memory overhead.
> >
> > Historically, zsmalloc had significantly worse latency than zbud and
> > z3fold but offered better memory savings.  This is no longer the case as
> > shown by a simple recent analysis [1].  In a kernel build test on tmpfs
> > in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost
> > of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make
> > sense for zbud in any practical scenario.
> >
> > The only alleged advantage of zbud is not having the dependency on
> > CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and
> > zbud is only used by zswap.
> >
> > Following in the footsteps of [2], which deprecated z3fold, deprecated
> > zbud as planned and remove it in a few cycles if no objections are
> > raised from active users.
> >
> > Rename the user-visible config options so that users with CONFIG_ZBUD=y
> > get a new prompt with explanation during make oldconfig. Also, remove
> > CONFIG_ZBUD from defconfig.
> >
> > [1]
> > https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/
> > [2]
> > https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/
> >
> > Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
> >
> 
> Let me disagree here. The footprint for zbud and the ability to work in
> MMU-less setups make it self sufficient and I don't support its deprecation.
> I can give a formal NAK if that's required.

What's the advtange of the ability to work on MMU-less setups when
CONFIG_SWAP itself depends on MMU? Please elaborate.

I agree that zbud has a smaller footprint, but I don't think that's
enough reason to keep it around if it's not being used, especially that
its memory utilization is really low.

Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[Seth Jennings]

On Tue, Jan 28, 2025 at 9:37 AM Yosry Ahmed <yosry.ahmed@linux.dev> wrote:
>
> On Tue, Jan 28, 2025 at 11:21:10AM +0100, Vlastimil Babka wrote:
> > On 1/28/25 00:58, Yosry Ahmed wrote:
> > > The zbud compressed pages allocator is rarely used, most users use
> > > zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed
> > > pages per physical page). The only advantage of zbud is a marginal
> > > performance improvement that by no means justify the memory overhead.
> > >
> > > Historically, zsmalloc had significantly worse latency than zbud and
> > > z3fold but offered better memory savings.  This is no longer the case as
> > > shown by a simple recent analysis [1].  In a kernel build test on tmpfs
> > > in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost
> > > of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make
> > > sense for zbud in any practical scenario.
> > >
> > > The only alleged advantage of zbud is not having the dependency on
> > > CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and
> > > zbud is only used by zswap.
> > >
> > > Following in the footsteps of [2], which deprecated z3fold, deprecated
> > > zbud as planned and remove it in a few cycles if no objections are
> > > raised from active users.
> > >
> > > Rename the user-visible config options so that users with CONFIG_ZBUD=y
> > > get a new prompt with explanation during make oldconfig. Also, remove
> > > CONFIG_ZBUD from defconfig.
> > >
> > > [1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/
> > > [2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/
> > >
> > > Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
> >
> > Seems weird not to Cc the folks listed in MAINTAINERS for ZBUD? Unless their
> > addresses are known to bounce?
>
> Ugh I had them in the CC list, but I played around with it and probably
> lost them :/
>
> Seth, Dan, apologies.

I haven't contributed in this space for quite some time so I defer to
more active contributors on this.

If it is true that zsmalloc has no/negligible deficiencies compared to
zbud, it seems reasonable.

> but at the cost of using ~32% more memory

I do push back here as this % could be highly variable depending on
the compressibility of the data.

If the average compressibility is ~50%, zbud should be very memory efficient.

If the average compressibility is very high or very low, it is less
memory efficient.

>
> > And ZRAM maintainers should also be Ccd?
>
> ZRAM does not use zbud, I can definitely CC them but I don't want to be
> a source of noise :)
>

Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[Yosry Ahmed]

On Tue, Jan 28, 2025 at 10:04:27AM -0600, Seth Jennings wrote:
> On Tue, Jan 28, 2025 at 9:37 AM Yosry Ahmed <yosry.ahmed@linux.dev> wrote:
> >
> > On Tue, Jan 28, 2025 at 11:21:10AM +0100, Vlastimil Babka wrote:
> > > On 1/28/25 00:58, Yosry Ahmed wrote:
> > > > The zbud compressed pages allocator is rarely used, most users use
> > > > zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed
> > > > pages per physical page). The only advantage of zbud is a marginal
> > > > performance improvement that by no means justify the memory overhead.
> > > >
> > > > Historically, zsmalloc had significantly worse latency than zbud and
> > > > z3fold but offered better memory savings.  This is no longer the case as
> > > > shown by a simple recent analysis [1].  In a kernel build test on tmpfs
> > > > in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost
> > > > of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make
> > > > sense for zbud in any practical scenario.
> > > >
> > > > The only alleged advantage of zbud is not having the dependency on
> > > > CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and
> > > > zbud is only used by zswap.
> > > >
> > > > Following in the footsteps of [2], which deprecated z3fold, deprecated
> > > > zbud as planned and remove it in a few cycles if no objections are
> > > > raised from active users.
> > > >
> > > > Rename the user-visible config options so that users with CONFIG_ZBUD=y
> > > > get a new prompt with explanation during make oldconfig. Also, remove
> > > > CONFIG_ZBUD from defconfig.
> > > >
> > > > [1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/
> > > > [2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/
> > > >
> > > > Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
> > >
> > > Seems weird not to Cc the folks listed in MAINTAINERS for ZBUD? Unless their
> > > addresses are known to bounce?
> >
> > Ugh I had them in the CC list, but I played around with it and probably
> > lost them :/
> >
> > Seth, Dan, apologies.
> 
> I haven't contributed in this space for quite some time so I defer to
> more active contributors on this.
> 
> If it is true that zsmalloc has no/negligible deficiencies compared to
> zbud, it seems reasonable.

Zsmalloc has been the default allocator and is widely used, I am unaware
of any zbud users in prod settings.

> > but at the cost of using ~32% more memory
> 
> I do push back here as this % could be highly variable depending on
> the compressibility of the data.

100% agreed, this is just an example from this specific testing
scenario.

> If the average compressibility is ~50%, zbud should be very memory efficient.
> 
> If the average compressibility is very high or very low, it is less
> memory efficient.

That being said, the average compression ratio hovers around 30% for
workloads I am familiar with. I think I have seen similar ratios from
others as well but I will let others chime in.

Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[Shakeel Butt]

On Mon, Jan 27, 2025 at 11:58:21PM +0000, Yosry Ahmed wrote:
> The zbud compressed pages allocator is rarely used, most users use
> zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed
> pages per physical page). The only advantage of zbud is a marginal
> performance improvement that by no means justify the memory overhead.
> 
> Historically, zsmalloc had significantly worse latency than zbud and
> z3fold but offered better memory savings.  This is no longer the case as
> shown by a simple recent analysis [1].  In a kernel build test on tmpfs
> in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost
> of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make
> sense for zbud in any practical scenario.
> 
> The only alleged advantage of zbud is not having the dependency on
> CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and
> zbud is only used by zswap.
> 
> Following in the footsteps of [2], which deprecated z3fold, deprecated
> zbud as planned and remove it in a few cycles if no objections are
> raised from active users.
> 
> Rename the user-visible config options so that users with CONFIG_ZBUD=y
> get a new prompt with explanation during make oldconfig. Also, remove
> CONFIG_ZBUD from defconfig.
> 
> [1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/
> [2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/
> 
> Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>

Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>

Re: [PATCH 1/2] mm: zbud: deprecate CONFIG_ZBUD

[Nhat Pham]

On Mon, Jan 27, 2025 at 3:58 PM Yosry Ahmed <yosry.ahmed@linux.dev> wrote:
>
> The zbud compressed pages allocator is rarely used, most users use
> zsmalloc. zbud consumes much more memory (only stores 1 or 2 compressed
> pages per physical page). The only advantage of zbud is a marginal
> performance improvement that by no means justify the memory overhead.
>
> Historically, zsmalloc had significantly worse latency than zbud and
> z3fold but offered better memory savings.  This is no longer the case as
> shown by a simple recent analysis [1].  In a kernel build test on tmpfs
> in a limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost
> of using ~32% more memory (1.5G vs 1.13G). The tradeoff does not make
> sense for zbud in any practical scenario.
>
> The only alleged advantage of zbud is not having the dependency on
> CONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and
> zbud is only used by zswap.
>
> Following in the footsteps of [2], which deprecated z3fold, deprecated
> zbud as planned and remove it in a few cycles if no objections are
> raised from active users.
>
> Rename the user-visible config options so that users with CONFIG_ZBUD=y
> get a new prompt with explanation during make oldconfig. Also, remove
> CONFIG_ZBUD from defconfig.
>
> [1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/
> [2]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/
>
> Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>

Acked-by: Nhat Pham <nphamcs@gmail.com>