linux-kernel - [PATCHv2 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-next>] [day] [month] [year] [list]

Date:   Thu, 19 Dec 2019 15:19:28 +0100
From:   Vitaly Wool <vitalywool@...il.com>
To:     Linux-MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dan Streetman <ddstreet@...e.org>,
        Minchan Kim <minchan@...nel.org>
Cc:     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: [PATCHv2 0/3] Allow ZRAM to use any zpool-compatible backend

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.

This patchset addresses the increasing demand to deploy ZRAM in systems
where zsmalloc is not a perfect match or is not applicable at all. An
example of a system of the first type is an embedded system using ZRAM
block device as a swap where quick application launch is critical for
good user experience since z3fold is substantially faster on read than
zsmalloc [2].

A system of the second type would, for instance, be the one with
hardware on-the-fly RAM compression/decompression where the saved RAM
space could be used for ZRAM but would require a special allocator.

The preliminary results for this work have been delivered at Linux
Plumbers this year [3]. The talk at LPC ended in a consensus to continue
the work and pursue the goal of decoupling ZRAM from zsmalloc.

The current patchset has been stress tested on arm64 and x86_64 devices,
including the Dell laptop I'm writing this message on now, not to mention
several QEmu confugirations.

The first version of this patchset can be found at [4].
Changelog since V1:
* better formatting
* allocator backend is now configurable on a per-ZRAM device basis
* allocator backend is runtime configurable via sysfs 

[1] https://lkml.org/lkml/2015/9/14/356
[2] https://lkml.org/lkml/2019/10/21/743
[3] https://linuxplumbersconf.org/event/4/contributions/551/
[4] https://lkml.org/lkml/2019/10/10/1046