Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Date:   Tue, 26 Sep 2023 17:26:40 -0400
From:   Johannes Weiner <hannes@cmpxchg.org>
To:     Nhat Pham <nphamcs@gmail.com>
Cc:     Christoph Hellwig <hch@infradead.org>, akpm@linux-foundation.org,
        cerasuolodomenico@gmail.com, yosryahmed@google.com,
        sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com,
        linux-mm@kvack.org, kernel-team@meta.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] zswap: change zswap's default allocator to zsmalloc
Message-ID: <20230926212640.GC348484@cmpxchg.org>
References: <20230908235115.2943486-1-nphamcs@gmail.com>
 <ZRKIRyYYkAbJ5uOP@infradead.org>
 <CAKEwX=O3ydrSKoZKv-6T0QHTEh5WkgRfK3b7Aa_H6GmQbn4QsA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAKEwX=O3ydrSKoZKv-6T0QHTEh5WkgRfK3b7Aa_H6GmQbn4QsA@mail.gmail.com>
Precedence: bulk

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.