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]
Message-ID: <20191014103341.GA36860@jagdpanzerIV>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ