Files
kernel/include/linux
Jens Axboe 21c6e939a9 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>
2017-04-28 08:11:43 -06:00
..
2017-03-07 14:30:38 +01:00
2017-02-10 15:52:24 -05:00
2017-02-24 17:46:55 -08:00
2017-02-04 00:47:59 +01:00
2017-02-27 10:07:47 -08:00
2017-03-12 23:51:34 -07:00
2017-04-20 12:09:55 -06:00
2017-03-22 00:18:22 -07:00
2017-02-11 20:59:41 -05:00
2017-03-22 16:16:17 +01:00
2017-02-24 17:46:57 -08:00
2017-03-01 09:50:58 -08:00
2017-03-02 08:56:04 -07:00
2017-02-13 21:44:09 -05:00
2017-02-27 18:43:46 -08:00
2017-02-03 11:19:34 -05:00
2017-02-03 10:17:02 +01:00
2017-02-10 16:34:17 +00:00
2017-03-21 14:41:46 -07:00
2017-02-02 15:22:18 -05:00