| Message ID | 20230908235115.2943486-1-nphamcs@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | zswap: change zswap's default allocator to zsmalloc | expand |
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>
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 >
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?
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? :)
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.
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
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(+)