zram: Allow zcomps to manage their own streams#628
Open
blktests-ci[bot] wants to merge 5 commits intolinus-master_basefrom
Open
zram: Allow zcomps to manage their own streams#628blktests-ci[bot] wants to merge 5 commits intolinus-master_basefrom
blktests-ci[bot] wants to merge 5 commits intolinus-master_basefrom
Conversation
Author
|
Upstream branch: 1f318b9 |
1f19ba6 to
e79276a
Compare
Author
|
Upstream branch: None |
1fb7767 to
feb8d89
Compare
e79276a to
0dd9afc
Compare
Author
|
Upstream branch: 80234b5 |
feb8d89 to
0b55309
Compare
0dd9afc to
2e598ed
Compare
Author
|
Upstream branch: 0257f64 |
0b55309 to
221b286
Compare
1b884bd to
3ff0536
Compare
added 5 commits
March 15, 2026 16:50
Currently, zcomp uses a preemptive per-CPU stream model where streams
are allocated for each online CPU and guarded by mutexes. The existing
names zcomp_strm_{init, free}() are too generic to explicitly indicate
they handle per-CPU streams.
Rename them to zcomp_strm_{init, free}_percpu(). This helps distinguish
them from future streams that may not be per-CPU based. No functional
changes are intended.
Signed-off-by: Jihan LIN <linjh22s@gmail.com>
Currently zcomp_strm has a lock for default per-CPU streams. This field should not be part of the generic stream structure. Remove lock from zcomp_strm, and introduce struct percpu_zstrm for per-CPU streams. This cleans up struct zcomp_strm and separates the stream definition from its locking policy. Signed-off-by: Jihan LIN <linjh22s@gmail.com>
Currently, zcomp uses a per-CPU stream model. This design is restrictive
for hardware-accelerated or batched zcomp backends. These backends often
need to manage their own resources rather than relying on a generic
mutex-protected per-CPU stream for batched operations.
Extend the zcomp interface to allow backends to optionally manage their
own streams while generic per-CPU streams still remain allocated as a
complementary mechanism.
Introduce zstrm_mgmt flag to struct zcomp_params. Backends set this flag
during zcomp_ops->setup_params() to advertise their capability to manage
streams.
Add zcomp_ops->{get, put}_stream() to allow zcomp backends to implement
their own stream strategies.
Modify zcomp_stream_get() to accept a new parameter indicating
zcomp-managed streams are preferred, and update zcomp_stream_put() to
route a zcomp-managed stream to the backend. If the backends advertise
their capability and the caller prefers managed streams, try to get a
stream from the backends; otherwise, fall back to the generic per-CPU
stream.
All existing call sites request the default per-CPU stream to preserve
the original behavior.
Signed-off-by: Jihan LIN <linjh22s@gmail.com>
Current per-CPU streams limit write concurrency to the number of online CPUs. Hardware accelerators with deep submission queues can handle far more concurrent requests. Use zcomp-managed streams for async write requests to take advantage of this. Modify zram_write_page() to accept a flag indicating the request is asynchronous. If the bio request is considered non-synchronous and the backend supports zcomp-managed streams, attempt to acquire one. zcomp_stream_get() handles the fallback to per-CPU streams. Sync writes block waiting for completion (e.g., blk_wait_io() in submit_bio_wait() from callers), and remain on per-CPU streams for per-request latency. Reads are unchanged since they are treated as synchronous operations. Recompression also remains unchanged as it prioritizes compression ratio. Although zram_write_page() currently waits for compression to complete, using zcomp-managed streams allows write concurrency to exceed the number of CPUs. Supporting multiple pages within a single bio request is deferred to keep it simple and focused. Signed-off-by: Jihan LIN <linjh22s@gmail.com>
This patch provides a proof-of-concept implementation of zcomp-managed streams for the lz4 backend, demonstrating how a hardware-accelerated compression backend would integrate with zcomp-managed streams introduced earlier in this series. The PoC simulates a hardware accelerator with a fixed queue depth of 128. Global stream buffers are shared across all zram devices, while contexts are per-device. Both are pre-allocated. During compression, requests are submitted to a double-buffered kfifo queue and processed by a dedicated kthread. Known limitations: - The single kthread serializes all compression work. - Pool sizes are hard-coded. - Uses global mutexes; contention is expected to be high under load. - Assumes !HIGHMEM; kmap_local_page mappings are passed to a kthread. Signed-off-by: Jihan LIN <linjh22s@gmail.com>
Author
|
Upstream branch: 0257f64 |
221b286 to
8283a3b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: zram: Allow zcomps to manage their own streams
version: 2
url: https://patchwork.kernel.org/project/linux-block/list/?series=1063640