From: Vitaly Wool <vitalywool@gmail.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Linux-MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dan Streetman <ddstreet@ieee.org>,
Minchan Kim <minchan@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Vlastimil Babka <vbabka@suse.cz>,
Shakeel Butt <shakeelb@google.com>,
Henry Burns <henrywolfeburns@gmail.com>,
"Theodore Ts'o" <tytso@thunk.org>
Subject: Re: [PATCH 0/3] Allow ZRAM to use any zpool-compatible backend
Date: Mon, 14 Oct 2019 13:49:41 +0200 [thread overview]
Message-ID: <CAMJBoFMO3jkdXMFvYAfqZ1_hnPufTRHGwpcFYqBBM2BD8dhwMQ@mail.gmail.com> (raw)
In-Reply-To: <20191014103341.GA36860@jagdpanzerIV>
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
next prev parent reply other threads:[~2019-10-14 11:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 20:04 [PATCH 0/3] Allow ZRAM to use any zpool-compatible backend Vitaly Wool
2019-10-10 20:09 ` [PATCH 1/3] zpool: extend API to match zsmalloc Vitaly Wool
2019-10-18 11:23 ` Dan Streetman
2019-10-10 20:11 ` [PATCH 2/3] zsmalloc: add compaction and huge class callbacks Vitaly Wool
2019-10-14 10:38 ` Sergey Senozhatsky
2019-10-10 20:20 ` [PATCH 3/3] zram: use common zpool interface Vitaly Wool
2019-10-14 10:47 ` Sergey Senozhatsky
2019-10-14 11:52 ` Vitaly Wool
2019-10-15 2:04 ` Sergey Senozhatsky
2019-10-14 10:33 ` [PATCH 0/3] Allow ZRAM to use any zpool-compatible backend Sergey Senozhatsky
2019-10-14 11:49 ` Vitaly Wool [this message]
2019-10-14 16:41 ` Minchan Kim
2019-10-14 16:50 ` Vitaly Wool
2019-10-15 7:39 ` Vitaly Wool
2019-10-15 20:00 ` Minchan Kim
2019-10-21 14:21 ` Vitaly Wool
2019-10-30 0:10 ` Minchan Kim
2019-11-13 15:54 ` Vitaly Wool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMJBoFMO3jkdXMFvYAfqZ1_hnPufTRHGwpcFYqBBM2BD8dhwMQ@mail.gmail.com \
--to=vitalywool@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ddstreet@ieee.org \
--cc=henrywolfeburns@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=shakeelb@google.com \
--cc=tytso@thunk.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.