kernel/linux.git/drivers/block/zram/zcomp.h, branch linux-7.0.y

zram: pass buffer offset to zcomp_available_show()

2025-07-04T01:56:51+00:00

In most cases zcomp_available_show() is the only emitting function that is called from sysfs read() handler, so it assumes that there is a whole PAGE_SIZE buffer to work with. There is an exception, however: recomp_algorithm_show(). In recomp_algorithm_show() we prepend the buffer with priority number before we pass it to zcomp_available_show(), so it cannot assume PAGE_SIZE anymore and must take recomp_algorithm_show() modifications into consideration. Therefore we need to pass buffer offset to zcomp_available_show(). Also convert it to use sysfs_emit_at(), to stay aligned with the rest of zram's sysfs read() handlers. On practice we are never even close to using the whole PAGE_SIZE buffer, so that's not a critical bug, but still. Signed-off-by: Sergey Senozhatsky Link: https://lore.kernel.org/r/20250627071840.1394242-1-senozhatsky@chromium.org Signed-off-by: Jens Axboe

zram: support deflate-specific params

2025-06-01T05:46:07+00:00

Introduce support of algorithm specific parameters in algorithm_params device attribute. The expected format is algorithm.param=value. For starters, add support for deflate.winbits parameter. Link: https://lkml.kernel.org/r/20250514024825.1745489-3-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Reviewed-by: Mikhail Zaslonko Cc: Minchan Kim Signed-off-by: Andrew Morton

zram: rename ZCOMP_PARAM_NO_LEVEL

2025-06-01T05:46:07+00:00

Patch series "zram: support algorithm-specific parameters". This patchset adds support for algorithm-specific parameters. For now, only deflate-specific winbits can be configured, which fixes deflate support on some s390 setups. This patch (of 2): Use more generic name because this will be default "un-set" value for more params in the future. Link: https://lkml.kernel.org/r/20250514024825.1745489-1-senozhatsky@chromium.org Link: https://lkml.kernel.org/r/20250514024825.1745489-2-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Reviewed-by: Mikhail Zaslonko Cc: Minchan Kim Signed-off-by: Andrew Morton

zram: switch to new zsmalloc object mapping API

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

Use new read/write zsmalloc object API. For cases when RO mapped object spans two physical pages (requires temp buffer) compression streams now carry around one extra physical page. Link: https://lkml.kernel.org/r/20250303022425.285971-16-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

zram: permit preemption with active compression stream

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

Currently, per-CPU stream access is done from a non-preemptible (atomic) section, which imposes the same atomicity requirements on compression backends as entry spin-lock, and makes it impossible to use algorithms that can schedule/wait/sleep during compression and decompression. Switch to preemptible per-CPU model, similar to the one used in zswap. Instead of a per-CPU local lock, each stream carries a mutex which is locked throughout entire time zram uses it for compression or decompression, so that cpu-dead event waits for zram to stop using a particular per-CPU stream and release it. Link: https://lkml.kernel.org/r/20250303022425.285971-3-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Suggested-by: Yosry Ahmed Reviewed-by: Yosry Ahmed Cc: Hillf Danton Cc: Kairui Song Cc: Minchan Kim Cc: Sebastian Andrzej Siewior Signed-off-by: Andrew Morton

zram: move immutable comp params away from per-CPU context

2024-09-09T23:39:10+00:00

Immutable params never change once comp has been allocated and setup, so we don't need to store multiple copies of them in each per-CPU backend context. Move those to per-comp zcomp_params and pass it to backends callbacks for requests execution. Basically, this means parameters sharing between different contexts. Also introduce two new backends callbacks: setup_params() and release_params(). First, we need to validate params in a driver-specific way; second, driver may want to allocate its specific representation of the params which is needed to execute requests. Link: https://lkml.kernel.org/r/20240902105656.1383858-20-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Nick Terrell Signed-off-by: Andrew Morton

zram: introduce zcomp_ctx structure

2024-09-09T23:39:10+00:00

Keep run-time driver data (scratch buffers, etc.) in zcomp_ctx structure. This structure is allocated per-CPU because drivers (backends) need to modify its content during requests execution. We will split mutable and immutable driver data, this is a preparation path. Link: https://lkml.kernel.org/r/20240902105656.1383858-19-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Nick Terrell Signed-off-by: Andrew Morton

zram: introduce zcomp_req structure

2024-09-09T23:39:10+00:00

Encapsulate compression/decompression data in zcomp_req structure. Link: https://lkml.kernel.org/r/20240902105656.1383858-18-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Nick Terrell Signed-off-by: Andrew Morton

zram: introduce zcomp_params structure

2024-09-09T23:39:09+00:00

We will store a per-algorithm parameters there (compression level, dictionary, dictionary size, etc.). Link: https://lkml.kernel.org/r/20240902105656.1383858-14-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Nick Terrell Signed-off-by: Andrew Morton

zram: introduce custom comp backends API

2024-09-09T23:39:07+00:00

Moving to custom backends implementation gives us ability to have our own minimalistic and extendable API, and algorithms tunings becomes possible. The list of compression backends is empty at this point, we will add backends in the followup patches. Link: https://lkml.kernel.org/r/20240902105656.1383858-5-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky Cc: Minchan Kim Cc: Nick Terrell Signed-off-by: Andrew Morton