diff options
author | Jens Axboe <axboe@fb.com> | 2017-04-10 17:54:56 +0200 |
---|---|---|
committer | Jens Axboe <axboe@fb.com> | 2017-04-28 16:11:43 +0200 |
commit | 21c6e939a9f6bb06fe616a87defec0f92a7c3df0 (patch) | |
tree | 4313793669d17a93b634236023d5ad3cf1c5ee22 /block/genhd.c | |
parent | block: add kblock_mod_delayed_work_on() (diff) | |
download | linux-21c6e939a9f6bb06fe616a87defec0f92a7c3df0.tar.xz linux-21c6e939a9f6bb06fe616a87defec0f92a7c3df0.zip |
blk-mq: unify hctx delay_work and run_work
The only difference between ->run_work and ->delay_work, is that
the latter is used to defer running a queue. This is done by
marking the queue stopped, and scheduling ->delay_work to run
sometime in the future. While the queue is stopped, direct runs
or runs through ->run_work will not run the queue.
If we combine the handlers, then we need to handle two things:
1) If a delayed/stopped run is scheduled, then we should not run
the queue before that has been completed.
2) If a queue is delayed/stopped, the handler needs to restart
the queue. Normally a run of a queue with the stopped bit set
would be a no-op.
Case 1 is handled by modifying a currently pending queue run
to the deadline set by the caller of blk_mq_delay_queue().
Subsequent attempts to queue a queue run will find the work
item already pending, and direct runs will see a stopped queue
as before.
Case 2 is handled by adding a new bit, BLK_MQ_S_START_ON_RUN,
that tells the work handler that it should clear a stopped
queue and run the handler.
Reviewed-by: Bart Van Assche <Bart.VanAssche@sandisk.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions