On Mon, Jan 15, 2024 at 4:27 AM Vitaly Wool <vitaly.wool@xxxxxxxxxxxx> wrote: > > On Fri, Jan 12, 2024 at 8:31 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > The z3fold compressed pages allocator is not widely used, most users use > > zsmalloc. The only disadvantage of zsmalloc in comparison is the > > dependency on MMU, and zbud is a more common option for !MMU as it was > > the default zswap allocator for a long time. > > > > In hopes of having a single compressed pages allocator at some point, > > and following in the footsteps of SLAB, deprecate z3fold. Rename the > > user-visible option so that users with CONFIG_Z3FOLD=y get a new prompt > > with explanation during make oldconfig. Remove CONFIG_Z3FOLD=y from > > defconfigs. > > I believe that having a single compressed pages allocator is a false goal. It's not a goal in itself for sure, but when most users use one allocator that is mostly superior, it makes sense to try to deprecate others. > > > Existing users, if any, should voice their objections. Otherwise, we can > > remove z3fold in a few releases. > > At this point I NACK this patch. We're about to submit an allocator > which is clearly better that z3fold and is faster that zsmalloc in > most cases and that submission will mark z3fold as deprecated. But for > now this move is premature. I think unless there are current users of z3fold that cannot use zsmalloc, the introduction of a new allocator should be irrelevant to deprecating z3fold. Do you know of such users? Can you explain why zsmalloc is not usable for them?
