[PATCHv2,0/3] Allow ZRAM to use any zpool-compatible backend

Message

Vitaly Wool Dec. 19, 2019, 2:19 p.m. UTC

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

Comments

Minchan Kim Dec. 20, 2019, 3:13 a.m. UTC | #1

On Thu, Dec 19, 2019 at 03:19:28PM +0100, 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.
> 
> 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].

Look https://lkml.org/lkml/2019/10/29/1169

z3fold read is 15% faster *only* when when compression ratio is bad below 50%
since zsmalloc involves copy operation if the object is located in the
boundary of discrete pages. It's never popular workload.
Even, once write is involved(write-only, mixed read-write), z3fold is always
slow. Think about that swap-in could cause swap out in the field because devices
are usually under memory pressure. Also, look at the memory usage.
zsmalloc saves bigger memory for all of compression ratios. 

You claims flexibility - some user want fast read. How do you guarantee
it is always fast? It depends on compression ratio. How can admin estimate
runtime data compression ratio in advance?  Their workload is read-only
if they use zram as swap? they are okay to lose write performance and memory
efficiency? Considering that, it's niche. I don't think it's worth to add
maintenance burden here for very limited usecase.

Think about why we replaced xvmalloc with zsmalloc instead of creating wrapper
to keep two allocators and why people push back so hard when we introduced even
zsmalloc. Why zbud was born at the cost of sacrificing memory efficiency was
concern about memory fragmenation of zsmalloc so freeing memory cannot make real
free memory so wanted to manage fragmentation limit(However, we introduced
object migration in zsmalloc afterward so the concern was gone now).

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

I agree. For the special compressor, we would need other allocator, even
huge zram changes in future for best performance. However, I'm not sure
zpool is good fit for the case. We need discussion when that kinds of
requirments comes up.

Nacked-by: Minchan Kim <[e-mail]>

Vitaly Wool Dec. 20, 2019, 6:04 a.m. UTC | #2

On Fri, Dec 20, 2019 at 4:14 AM Minchan Kim <[e-mail]> wrote:

<snip>
> Look https://lkml.org/lkml/2019/10/29/1169
>
> z3fold read is 15% faster *only* when when compression ratio is bad below 50%
> since zsmalloc involves copy operation if the object is located in the
> boundary of discrete pages. It's never popular workload.
> Even, once write is involved(write-only, mixed read-write), z3fold is always
> slow. Think about that swap-in could cause swap out in the field because devices
> are usually under memory pressure. Also, look at the memory usage.
> zsmalloc saves bigger memory for all of compression ratios.

Yes I remember that. Since your measurements were done on "an x86" without
providing any detail on the actual platform used, they are as good as none.

~Vitaly