[PATCH] zswap: change zswap's default allocator to zsmalloc

[PATCH] zswap: change zswap's default allocator to zsmalloc

[Nhat Pham]

Out of zswap's 3 allocators, zsmalloc is the clear superior in terms of
memory utilization, both in theory and as observed in practice, with its
high storage density and low internal fragmentation. zsmalloc is also
more actively developed and maintained, since it is the allocator of
choice for zswap for many users, as well as the only allocator for zram.

A historical objection to the selection of zsmalloc as the default
allocator for zswap is its lack of writeback capability. However, this
has changed, with the zsmalloc writeback patchset, and the subsequent
zswap LRU refactor. With this, there is not a lot of good reasons to
keep zbud, an otherwise inferior allocator, as the default instead of
zswap.

This patch changes the default allocator to zsmalloc. The only exception
is on settings without MMU, in which case zbud will remain as the
default.

Signed-off-by: Nhat Pham <nphamcs@gmail.com>
---
 mm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/Kconfig b/mm/Kconfig
index 721dc88423c7..e0217deca084 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -130,6 +130,7 @@ config ZSWAP_COMPRESSOR_DEFAULT
 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
-- 
2.34.1

Re: [PATCH] zswap: change zswap's default allocator to zsmalloc

[Johannes Weiner]

On Fri, Sep 08, 2023 at 04:51:15PM -0700, Nhat Pham wrote:
> Out of zswap's 3 allocators, zsmalloc is the clear superior in terms of
> memory utilization, both in theory and as observed in practice, with its
> high storage density and low internal fragmentation. zsmalloc is also
> more actively developed and maintained, since it is the allocator of
> choice for zswap for many users, as well as the only allocator for zram.
> 
> A historical objection to the selection of zsmalloc as the default
> allocator for zswap is its lack of writeback capability. However, this
> has changed, with the zsmalloc writeback patchset, and the subsequent
> zswap LRU refactor. With this, there is not a lot of good reasons to
> keep zbud, an otherwise inferior allocator, as the default instead of
> zswap.
> 
> This patch changes the default allocator to zsmalloc. The only exception
> is on settings without MMU, in which case zbud will remain as the
> default.
> 
> Signed-off-by: Nhat Pham <nphamcs@gmail.com>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

Re: [PATCH] zswap: change zswap's default allocator to zsmalloc

[Yosry Ahmed]

On Fri, Sep 8, 2023 at 4:51 PM Nhat Pham <nphamcs@gmail.com> wrote:
>
> Out of zswap's 3 allocators, zsmalloc is the clear superior in terms of
> memory utilization, both in theory and as observed in practice, with its
> high storage density and low internal fragmentation. zsmalloc is also
> more actively developed and maintained, since it is the allocator of
> choice for zswap for many users, as well as the only allocator for zram.
>
> A historical objection to the selection of zsmalloc as the default
> allocator for zswap is its lack of writeback capability. However, this
> has changed, with the zsmalloc writeback patchset, and the subsequent
> zswap LRU refactor. With this, there is not a lot of good reasons to
> keep zbud, an otherwise inferior allocator, as the default instead of
> zswap.
>
> This patch changes the default allocator to zsmalloc. The only exception
> is on settings without MMU, in which case zbud will remain as the
> default.
>
> Signed-off-by: Nhat Pham <nphamcs@gmail.com>

Acked-by: Yosry Ahmed <yosryahmed@google.com>

> ---
>  mm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 721dc88423c7..e0217deca084 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -130,6 +130,7 @@ config ZSWAP_COMPRESSOR_DEFAULT
>  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
> --
> 2.34.1
>

Re: [PATCH] zswap: change zswap's default allocator to zsmalloc

[Christoph Hellwig]

On Fri, Sep 08, 2023 at 04:51:15PM -0700, Nhat Pham wrote:
> Out of zswap's 3 allocators, zsmalloc is the clear superior in terms of
> memory utilization, both in theory and as observed in practice, with its
> high storage density and low internal fragmentation. zsmalloc is also
> more actively developed and maintained, since it is the allocator of
> choice for zswap for many users, as well as the only allocator for zram.

Dumb question from an outside, why do we then even keep the other
two allocators around?

Re: [PATCH] zswap: change zswap's default allocator to zsmalloc

[Nhat Pham]

On Tue, Sep 26, 2023 at 12:29 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Fri, Sep 08, 2023 at 04:51:15PM -0700, Nhat Pham wrote:
> > Out of zswap's 3 allocators, zsmalloc is the clear superior in terms of
> > memory utilization, both in theory and as observed in practice, with its
> > high storage density and low internal fragmentation. zsmalloc is also
> > more actively developed and maintained, since it is the allocator of
> > choice for zswap for many users, as well as the only allocator for zram.
>
> Dumb question from an outside, why do we then even keep the other
> two allocators around?
>

Maybe legacy users who explicitly configure zbud/z3fold?
We have a couple internally, and have to manually undo
those configuration after we stop compiling these 2
allocators.

But yeah, I don't see why we should keep these 2 allocators
around. Time to deprecate them? :)

Re: [PATCH] zswap: change zswap's default allocator to zsmalloc

[Johannes Weiner]

On Tue, Sep 26, 2023 at 01:06:13PM -0700, Nhat Pham wrote:
> On Tue, Sep 26, 2023 at 12:29 AM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Fri, Sep 08, 2023 at 04:51:15PM -0700, Nhat Pham wrote:
> > > Out of zswap's 3 allocators, zsmalloc is the clear superior in terms of
> > > memory utilization, both in theory and as observed in practice, with its
> > > high storage density and low internal fragmentation. zsmalloc is also
> > > more actively developed and maintained, since it is the allocator of
> > > choice for zswap for many users, as well as the only allocator for zram.
> >
> > Dumb question from an outside, why do we then even keep the other
> > two allocators around?
> >
> 
> Maybe legacy users who explicitly configure zbud/z3fold?
> We have a couple internally, and have to manually undo
> those configuration after we stop compiling these 2
> allocators.
> 
> But yeah, I don't see why we should keep these 2 allocators
> around. Time to deprecate them? :)

I agree we should try to get rid of them. The best reason for them I
can come up with is that they're more "lightweight". But I'm not sure
that pans out in practice. Even if loads and stores are marginally
faster, the poor density means you have to reclaim more/hotter anon
pages for the equivalent reduction in memory usage. In most cases this
will increase the overall amount of ongoing paging. That should
quickly dwarve the minor advantage in per-transaction overhead.

We could do something similar as we did for slab and mark them
deprecated for a few cycles:

commit eb07c4f39c3e858a7d0cc4bb15b8a304f83f0497
Author: Vlastimil Babka <vbabka@suse.cz>
Date:   Tue May 23 09:06:34 2023 +0200

    mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED

Then if nobody complains give them the ax.