-
Notifications
You must be signed in to change notification settings - Fork 0
zram: introduce writeback bio batching #360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: linus-master_base
Are you sure you want to change the base?
Conversation
|
Upstream branch: 6da43bb |
|
Upstream branch: 6da43bb |
a6bfffb to
92ffc73
Compare
83d3e2f to
00d5e5c
Compare
|
Upstream branch: f824272 |
92ffc73 to
67ff285
Compare
00d5e5c to
d782508
Compare
|
Upstream branch: f824272 |
67ff285 to
87cc234
Compare
d782508 to
6099a4d
Compare
|
Upstream branch: e7c375b |
87cc234 to
629631a
Compare
6099a4d to
5121c4d
Compare
|
Upstream branch: e7c375b |
629631a to
2f2b7e2
Compare
|
Upstream branch: e7c375b |
2f2b7e2 to
ac79ec3
Compare
5121c4d to
4458758
Compare
|
Upstream branch: 8b69055 |
ac79ec3 to
78ebb55
Compare
|
Upstream branch: 8b69055 |
78ebb55 to
b152c00
Compare
|
Upstream branch: 8b69055 |
b152c00 to
e253968
Compare
|
Upstream branch: 8b69055 |
e253968 to
55fceb5
Compare
4458758 to
6f43942
Compare
|
Upstream branch: fd95357 |
55fceb5 to
0088743
Compare
As was stated in a comment [1] a single page writeback IO is not efficient, but it works. It's time to address this throughput limitation as writeback becomes used more often. Introduce batched (multiple) bio writeback support to take advantage of parallel requests processing and better requests scheduling. Approach used in this patch doesn't use a dedicated kthread like in [2], or blk-plug like in [3]. Dedicated kthread adds complexity, which can be avoided. Apart from that not all zram setups use writeback, so having numerous per-device kthreads (on systems that create multiple zram devices) hanging around is not the most optimal thing to do. blk-plug, on the other hand, works best when request are sequential, which doesn't particularly fit zram writebck IO patterns: zram writeback IO patterns are expected to be random, due to how bdev block reservation/release are handled. blk-plug approach also works in cycles: idle IO, when zram sets up requests in a batch, is followed by bursts of IO, when zram submits the entire batch. Instead we use a batch of requests and submit new bio as soon as one of the in-flight requests completes. For the time being the writeback batch size (maximum number of in-flight bio requests) is set to 32 for all devices. A follow up patch adds a writeback_batch_size device attribute, so the batch size becomes run-time configurable. [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/all/[email protected]/ [3] https://lore.kernel.org/all/[email protected]/ Signed-off-by: Sergey Senozhatsky <[email protected]> Co-developed-by: Yuwen Chen <[email protected]> Co-developed-by: Richard Chang <[email protected]> Suggested-by: Minchan Kim <[email protected]>
Introduce writeback_batch_size device attribute so that the maximum number of in-flight writeback bio requests can be configured at run-time per-device. This essentially enables batched bio writeback. Signed-off-by: Sergey Senozhatsky <[email protected]>
Write device attrs handlers should take write zram init_lock. While at it, fixup coding styles. Signed-off-by: Sergey Senozhatsky <[email protected]> Reviewed-by: Brian Geffon <[email protected]>
We don't need wb_limit_lock. Writeback limit setters take an exclusive write zram init_lock, while wb_limit modifications happen only from a single task and under zram read init_lock. No concurrent wb_limit modifications are possible (we permit only one post-processing task at a time). Add lockdep assertions to wb_limit mutators. While at it, fixup coding styles. Signed-off-by: Sergey Senozhatsky <[email protected]> Reviewed-by: Brian Geffon <[email protected]>
First, writeback bdev ->bitmap bits are set only from one context, as we can have only one single task performing writeback, so we cannot race with anything else. Remove retry path. Second, we always check ZRAM_WB flag to distinguish writtenback slots, so we should not confuse 0 bdev block index and 0 handle. We can use first bdev block (0 bit) for writeback as well. While at it, give functions slightly more accurate names, as we don't alloc/free anything there, we reserve a block for async writeback or release the block. Signed-off-by: Sergey Senozhatsky <[email protected]> Reviewed-by: Brian Geffon <[email protected]>
Read slot's block id under slot-lock. We release the slot-lock for bdev read so, technically, slot still can get freed in the meantime, but at least we will read bdev block (page) that holds previous know slot data, not from slot->handle bdev block, which can be anything at that point. Signed-off-by: Sergey Senozhatsky <[email protected]>
|
Upstream branch: fd95357 |
0088743 to
f907518
Compare
Pull request for series with
subject: zram: introduce writeback bio batching
version: 1
url: https://patchwork.kernel.org/project/linux-block/list/?series=1022850