Re: [PATCH 0/3] Allow ZRAM to use any zpool-compatible backend
From: Vitaly Wool
Date: Mon Oct 14 2019 - 07:49:56 EST
On Mon, Oct 14, 2019 at 12:35 PM Sergey Senozhatsky
> 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  and is notable for
> > the heated discussions it has caused.
> Oh, right, I do recall it.
> > The patchset in  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:
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 . 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.
> >  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 :)