]> git.ipfire.org Git - thirdparty/kernel/linux.git/commitdiff
zram: update recompression documentation
authorSergey Senozhatsky <senozhatsky@chromium.org>
Wed, 11 Mar 2026 08:42:47 +0000 (17:42 +0900)
committerAndrew Morton <akpm@linux-foundation.org>
Sun, 5 Apr 2026 20:53:24 +0000 (13:53 -0700)
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 <senozhatsky@chromium.org>
Cc: Brian Geffon <bgeffon@google.com>
Cc: gao xu <gaoxu2@honor.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Documentation/admin-guide/blockdev/zram.rst

index 451fa00d3004b5ed1b37e042200938661d381e95..967b58c3aad2437da52f15cf315d5e75753dceb4 100644 (file)
@@ -462,7 +462,7 @@ know it via /sys/block/zram0/bd_stat's 3rd column.
 recompression
 -------------
 
-With CONFIG_ZRAM_MULTI_COMP, zram can recompress pages using alternative
+With `CONFIG_ZRAM_MULTI_COMP`, zram can recompress pages using alternative
 (secondary) compression algorithms. The basic idea is that alternative
 compression algorithm can provide better compression ratio at a price of
 (potentially) slower compression/decompression speeds. Alternative compression
@@ -471,7 +471,7 @@ that default algorithm failed to compress). Another application is idle pages
 recompression - pages that are cold and sit in the memory can be recompressed
 using more effective algorithm and, hence, reduce zsmalloc memory usage.
 
-With CONFIG_ZRAM_MULTI_COMP, zram supports up to 4 compression algorithms:
+With `CONFIG_ZRAM_MULTI_COMP`, zram supports up to 4 compression algorithms:
 one primary and up to 3 secondary ones. Primary zram compressor is explained
 in "3) Select compression algorithm", secondary algorithms are configured
 using recomp_algorithm device attribute.
@@ -495,34 +495,43 @@ configuration:::
        #select deflate recompression algorithm, priority 2
        echo "algo=deflate priority=2" > /sys/block/zramX/recomp_algorithm
 
-Another device attribute that CONFIG_ZRAM_MULTI_COMP enables is recompress,
+Another device attribute that `CONFIG_ZRAM_MULTI_COMP` enables is `recompress`,
 which controls recompression.
 
 Examples:::
 
        #IDLE pages recompression is activated by `idle` mode
-       echo "type=idle" > /sys/block/zramX/recompress
+       echo "type=idle priority=1" > /sys/block/zramX/recompress
 
        #HUGE pages recompression is activated by `huge` mode
-       echo "type=huge" > /sys/block/zram0/recompress
+       echo "type=huge priority=2" > /sys/block/zram0/recompress
 
        #HUGE_IDLE pages recompression is activated by `huge_idle` mode
-       echo "type=huge_idle" > /sys/block/zramX/recompress
+       echo "type=huge_idle priority=1" > /sys/block/zramX/recompress
 
 The number of idle pages can be significant, so user-space can pass a size
 threshold (in bytes) to the recompress knob: zram will recompress only pages
 of equal or greater size:::
 
        #recompress all pages larger than 3000 bytes
-       echo "threshold=3000" > /sys/block/zramX/recompress
+       echo "threshold=3000 priority=1" > /sys/block/zramX/recompress
 
        #recompress idle pages larger than 2000 bytes
-       echo "type=idle threshold=2000" > /sys/block/zramX/recompress
+       echo "type=idle threshold=2000 priority=1" > \
+               /sys/block/zramX/recompress
 
 It is also possible to limit the number of pages zram re-compression will
 attempt to recompress:::
 
-       echo "type=huge_idle max_pages=42" > /sys/block/zramX/recompress
+       echo "type=huge_idle priority=1 max_pages=42" > \
+               /sys/block/zramX/recompress
+
+It is advised to always specify `priority` parameter.  While it is also
+possible to specify `algo` parameter, so that `zram` will use algorithm's
+name to determine the priority, it is not recommended, since it can lead to
+unexpected results when the same algorithm is configured with different
+priorities (e.g. different parameters).  `priority` is the only way to
+guarantee that the expected algorithm will be used.
 
 During re-compression for every page, that matches re-compression criteria,
 ZRAM iterates the list of registered alternative compression algorithms in
@@ -533,19 +542,6 @@ no secondary algorithms left to try. If none of the secondary algorithms can
 successfully re-compressed the page such a page is marked as incompressible,
 so ZRAM will not attempt to re-compress it in the future.
 
-This re-compression behaviour, when it iterates through the list of
-registered compression algorithms, increases our chances of finding the
-algorithm that successfully compresses a particular page. Sometimes, however,
-it is convenient (and sometimes even necessary) to limit recompression to
-only one particular algorithm so that it will not try any other algorithms.
-This can be achieved by providing a `algo` or `priority` parameter:::
-
-       #use zstd algorithm only (if registered)
-       echo "type=huge algo=zstd" > /sys/block/zramX/recompress
-
-       #use zstd algorithm only (if zstd was registered under priority 1)
-       echo "type=huge priority=1" > /sys/block/zramX/recompress
-
 memory tracking
 ===============