| Message ID | Z5gdnSX5Lv-nfjQL@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: zswap: deprecate zbud and remove z3fold | expand |
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.
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?
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 > >
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.
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 :)
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.
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 :) >
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.
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>
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>
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
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(-)