lwn.git/Documentation/admin-guide/blockdev/zram.rst, branch docs-mw

zram: remove chained recompression

2026-04-05T20:53:24+00:00

Chained recompression has unpredictable behavior and is not useful in practice. First, systems usually configure just one alternative recompression algorithm, which has slower compression/decompression but better compression ratio. A single alternative algorithm doesn't need chaining. Second, even with multiple recompression algorithms, chained recompression is suboptimal. If a lower priority algorithm succeeds, the page is never attempted with a higher priority algorithm, leading to worse memory savings. If a lower priority algorithm fails, the page is still attempted with a higher priority algorithm, wasting resources on the failed lower priority attempt. In either case, the system would be better off targeting a specific priority directly. Chained recompression also significantly complicates the code. Remove it. Link: https://lkml.kernel.org/r/20260311084312.1766036-6-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Brian Geffon Cc: gao xu Cc: Jens Axboe Cc: Minchan Kim Signed-off-by: Andrew Morton

zram: update recompression documentation

2026-04-05T20:53:24+00:00

Emphasize usage of the `priority` parameter for recompression and explain why `algo` parameter can lead to unexpected behavior and thus is not recommended. Link: https://lkml.kernel.org/r/20260311084312.1766036-5-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Brian Geffon Cc: gao xu Cc: Jens Axboe Cc: Minchan Kim Signed-off-by: Andrew Morton

zram: rename writeback_compressed device attr

2026-03-04T17:44:23+00:00

Rename writeback_compressed attr to compressed_writeback to avoid possible confusion and have more natural naming. writeback_compressed may look like an alternative version of writeback while in fact writeback_compressed only sets a writeback property. Make this distinction more clear with a new compressed_writeback name. This updates a feature which is new in 7.0-rcX. Link: https://lkml.kernel.org/r/20260226025429.1042083-1-senozhatsky@chromium.org Fixes: 4c1d61389e8e ("zram: introduce writeback_compressed device attribute") Signed-off-by: Sergey Senozhatsky Suggested-by: Minchan Kim Acked-by: Minchan Kim Cc: Brian Geffon Cc: Richard Chang Cc: Suren Baghdasaryan Cc: "Christoph Böhmwalder" Cc: Jens Axboe Cc: Jonathan Corbet Cc: Lars Ellenberg Cc: Philipp Reisner Cc: Shuah Khan Signed-off-by: Andrew Morton

zram: document writeback_batch_size

2026-01-21T03:24:36+00:00

Add missing writeback_batch_size documentation. Link: https://lkml.kernel.org/r/20251201094754.4149975-4-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Brian Geffon Cc: David Stevens Cc: Minchan Kim Cc: Richard Chang Signed-off-by: Andrew Morton

zram: introduce writeback_compressed device attribute

2026-01-21T03:24:36+00:00

Introduce witeback_compressed device attribute to toggle compressed writeback (decompression on demand) feature. [senozhatsky@chromium.org: rewrote original patch, added documentation] Link: https://lkml.kernel.org/r/20251201094754.4149975-3-senozhatsky@chromium.org Signed-off-by: Richard Chang Co-developed-by: Sergey Senozhatsky Signed-off-by: Sergey Senozhatsky Cc: Brian Geffon Cc: David Stevens Cc: Minchan Kim Signed-off-by: Andrew Morton

Documentation: zram: update IDLE pages tracking documentation

2025-05-12T00:48:33+00:00

Move IDLE pages tracking into a separate chapter because there are multiple features that use (or depend on) it either in built-in variant ("mark all") or in extended variant (ac-time tracking). In addition, recompression doesn't require memory tracking to be enabled in order to be able to perform idle recompression. Link: https://lkml.kernel.org/r/20250416042833.3858827-1-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Reported-by: Shin Kawamura Cc: Jonathan Corbet Cc: Minchan Kim Signed-off-by: Andrew Morton

zram: modernize writeback interface

2025-05-12T00:48:09+00:00

The writeback interface supports a page_index=N parameter which performs writeback of the given page. Since we rarely need to writeback just one single page, the typical use case involves a number of writeback calls, each performing writeback of one page: echo page_index=100 > zram0/writeback ... echo page_index=200 > zram0/writeback echo page_index=500 > zram0/writeback ... echo page_index=700 > zram0/writeback One obvious downside of this is that it increases the number of syscalls. Less obvious, but a significantly more important downside, is that when given only one page to post-process zram cannot perform an optimal target selection. This becomes a critical limitation when writeback_limit is enabled, because under writeback_limit we want to guarantee the highest memory savings hence we first need to writeback pages that release the highest amount of zsmalloc pool memory. This patch adds page_indexes=LOW-HIGH parameter to the writeback interface: echo page_indexes=100-200 page_indexes=500-700 > zram0/writeback This gives zram a chance to apply an optimal target selection strategy on each iteration of the writeback loop. We also now permit multiple page_index parameters per call (previously zram would recognize only one page_index) and a mix or single pages and page ranges: echo page_index=42 page_index=99 page_indexes=100-200 \ page_indexes=500-700 > zram0/writeback Apart from that the patch also unifies parameters passing and resembles other "modern" zram device attributes (e.g. recompression), while the old interface used a mixed scheme: values-less parameters for mode and a key=value format for page_index. We still support the "old" value-less format for compatibility reasons. [senozhatsky@chromium.org: simplify parse_page_index() range checks, per Brian] nk: https://lkml.kernel.org/r/20250404015327.2427684-1-senozhatsky@chromium.org [sozhatsky@chromium.org: fix uninitialized variable in zram_writeback_slots(), per Dan] nk: https://lkml.kernel.org/r/20250409112611.1154282-1-senozhatsky@chromium.org Link: https://lkml.kernel.org/r/20250327015818.4148660-1-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Reviewed-by: Brian Geffon Cc: Minchan Kim Cc: Richard Chang Cc: Sergey Senozhatsky Cc: Dan Carpenter Signed-off-by: Andrew Morton

zram: remove max_comp_streams device attr

2025-03-17T05:06:33+00:00

max_comp_streams device attribute has been defunct since May 2016 when zram switched to per-CPU compression streams, remove it. Link: https://lkml.kernel.org/r/20250303022425.285971-5-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Hillf Danton Cc: Kairui Song Cc: Minchan Kim Cc: Sebastian Andrzej Siewior Cc: Yosry Ahmed Signed-off-by: Andrew Morton

Documentation: zram: fix dictionary spelling

2024-12-13T15:52:22+00:00

Fixes a typo in the ZRAM documentation where 'dictioary' was misspelled. Corrected it to 'dictionary' in the example usage of 'algorithm_params'. Signed-off-by: Sarveshwaar SS Reviewed-by: Sergey Senozhatsky Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20241125165122.17521-1-sarvesh20123@gmail.com

zram: permit only one post-processing operation at a time

2024-11-06T00:56:22+00:00

Both recompress and writeback soon will unlock slots during processing, which makes things too complex wrt possible race-conditions. We still want to clear PP_SLOT in slot_free, because this is how we figure out that slot that was selected for post-processing has been released under us and when we start post-processing we check if slot still has PP_SLOT set. At the same time, theoretically, we can have something like this: CPU0 CPU1 recompress scan slots set PP_SLOT unlock slot slot_free clear PP_SLOT allocate PP_SLOT writeback scan slots set PP_SLOT unlock slot select PP-slot test PP_SLOT So recompress will not detect that slot has been re-used and re-selected for concurrent writeback post-processing. Make sure that we only permit on post-processing operation at a time. So now recompress and writeback post-processing don't race against each other, we only need to handle slot re-use (slot_free and write), which is handled individually by each pp operation. Having recompress and writeback competing for the same slots is not exactly good anyway (can't imagine anyone doing that). Link: https://lkml.kernel.org/r/20240917021020.883356-3-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Minchan Kim Signed-off-by: Andrew Morton