Re: [PATCH 0/3] Allow ZRAM to use any zpool-compatible backend

[Vitaly Wool <vitalywool@gmail.com>]

Hi Sergey,

On Mon, Oct 14, 2019 at 12:35 PM Sergey Senozhatsky
<sergey.senozhatsky.work@gmail.com> wrote:
>
> Hi,
>
> On (10/10/19 23:04), Vitaly Wool wrote:
> [..]
> > The coming patchset is a new take on the old issue: ZRAM can
> > currently be used only with zsmalloc even though this may not
> > be the optimal combination for some configurations. The previous
> > (unsuccessful) attempt dates back to 2015 [1] and is notable for
> > the heated discussions it has caused.
>
> Oh, right, I do recall it.
>
> > The patchset in [1] had basically the only goal of enabling
> > ZRAM/zbud combo which had a very narrow use case. Things have
> > changed substantially since then, and now, with z3fold used
> > widely as a zswap backend, I, as the z3fold maintainer, am
> > getting requests to re-interate on making it possible to use
> > ZRAM with any zpool-compatible backend, first of all z3fold.
>
> A quick question, what are the technical reasons to prefer
> allocator X over zsmalloc? Some data would help, I guess.

For z3fold, the data can be found here:
https://elinux.org/images/d/d3/Z3fold.pdf.

For zbud (which is also of interest), imagine a low-end platform with
a simplistic HW compressor that doesn't give really high ratio. We
still want to be able to use ZRAM (not necessarily as a swap
partition, but rather for /home and /var) but we absolutely don't need
zsmalloc's complexity. zbud is a perfect match here (provided that it
can cope with PAGE_SIZE pages, yes, but it's a small patch to make
that work) since it's unlikely that we squeeze more than 2 compressed
pages per page with that HW compressor anyway.

> > The preliminary results for this work have been delivered at
> > Linux Plumbers this year [2]. The talk at LPC, though having
> > attracted limited interest, ended in a consensus to continue
> > the work and pursue the goal of decoupling ZRAM from zsmalloc.
>
> [..]
>
> > [1] https://lkml.org/lkml/2015/9/14/356
>
> I need to re-read it, thanks for the link. IIRC, but maybe
> I'm wrong, one of the things Minchan was not happy with was
> increased maintenance cost. So, perhaps, this also should
> be discuss/addressed (and maybe even in the first place).

I have hard time seeing how maintenance cost is increased here :)

~Vitaly