[lkml]   [2019]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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

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


 \ /
  Last update: 2019-12-19 15:20    [W:0.087 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site