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
