|author||Omar Sandoval <email@example.com>||2017-04-14 01:00:02 -0700|
|committer||Jens Axboe <firstname.lastname@example.org>||2017-04-14 14:06:58 -0600|
blk-mq: introduce Kyber multiqueue I/O scheduler
The Kyber I/O scheduler is an I/O scheduler for fast devices designed to scale to multiple queues. Users configure only two knobs, the target read and synchronous write latencies, and the scheduler tunes itself to achieve that latency goal. The implementation is based on "tokens", built on top of the scalable bitmap library. Tokens serve as a mechanism for limiting requests. There are two tiers of tokens: queueing tokens and dispatch tokens. A queueing token is required to allocate a request. In fact, these tokens are actually the blk-mq internal scheduler tags, but the scheduler manages the allocation directly in order to implement its policy. Dispatch tokens are device-wide and split up into two scheduling domains: reads vs. writes. Each hardware queue dispatches batches round-robin between the scheduling domains as long as tokens are available for that domain. These tokens can be used as the mechanism to enable various policies. The policy Kyber uses is inspired by active queue management techniques for network routing, similar to blk-wbt. The scheduler monitors latencies and scales the number of dispatch tokens accordingly. Queueing tokens are used to prevent starvation of synchronous requests by asynchronous requests. Various extensions are possible, including better heuristics and ionice support. The new scheduler isn't set as the default yet. Signed-off-by: Omar Sandoval <email@example.com> Signed-off-by: Jens Axboe <firstname.lastname@example.org>
Diffstat (limited to 'block/Kconfig.iosched')
1 files changed, 9 insertions, 0 deletions
diff --git a/block/Kconfig.iosched b/block/Kconfig.iosched
index 58fc868..916e69c 100644
@@ -69,6 +69,15 @@ config MQ_IOSCHED_DEADLINE
MQ version of the deadline IO scheduler.
+ tristate "Kyber I/O scheduler"
+ default y
+ The Kyber I/O scheduler is a low-overhead scheduler suitable for
+ multiqueue and other fast devices. Given target latencies for reads and
+ synchronous writes, it will self-tune queue depths to achieve that