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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 14 Oct 2019 19:33:41 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Vitaly Wool <vitalywool@...il.com>
Cc:     Linux-MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dan Streetman <ddstreet@...e.org>,
        Minchan Kim <minchan@...nel.org>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Shakeel Butt <shakeelb@...gle.com>,
        Henry Burns <henrywolfeburns@...il.com>,
        Theodore Ts'o <tytso@...nk.org>
Subject: Re: [PATCH 0/3] Allow ZRAM to use any zpool-compatible backend

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.

> 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).

	-ss