1. 02 5月, 2017 1 次提交
  2. 28 4月, 2017 2 次提交
    • J
      blk-mq: unify hctx delay_work and run_work · 21c6e939
      Jens Axboe 提交于
      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: NBart Van Assche <Bart.VanAssche@sandisk.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      21c6e939
    • J
      blk-mq: unify hctx delayed_run_work and run_work · 9f993737
      Jens Axboe 提交于
      They serve the exact same purpose. Get rid of the non-delayed
      work variant, and just run it without delay for the normal case.
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NBart Van Assche <Bart.VanAssche@sandisk.com>
      Reviewed-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      9f993737
  3. 27 4月, 2017 1 次提交
  4. 21 4月, 2017 1 次提交
  5. 15 4月, 2017 1 次提交
  6. 08 4月, 2017 1 次提交
  7. 05 4月, 2017 1 次提交
  8. 29 3月, 2017 1 次提交
  9. 23 3月, 2017 1 次提交
  10. 02 3月, 2017 2 次提交
  11. 24 2月, 2017 1 次提交
    • O
      blk-mq: use sbq wait queues instead of restart for driver tags · da55f2cc
      Omar Sandoval 提交于
      Commit 50e1dab8 ("blk-mq-sched: fix starvation for multiple hardware
      queues and shared tags") fixed one starvation issue for shared tags.
      However, we can still get into a situation where we fail to allocate a
      tag because all tags are allocated but we don't have any pending
      requests on any hardware queue.
      
      One solution for this would be to restart all queues that share a tag
      map, but that really sucks. Ideally, we could just block and wait for a
      tag, but that isn't always possible from blk_mq_dispatch_rq_list().
      
      However, we can still use the struct sbitmap_queue wait queues with a
      custom callback instead of blocking. This has a few benefits:
      
      1. It avoids iterating over all hardware queues when completing an I/O,
         which the current restart code has to do.
      2. It benefits from the existing rolling wakeup code.
      3. It avoids punting to another thread just to have it block.
      Signed-off-by: NOmar Sandoval <osandov@fb.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      da55f2cc
  12. 18 1月, 2017 3 次提交
  13. 12 1月, 2017 1 次提交
  14. 10 12月, 2016 1 次提交
  15. 09 11月, 2016 1 次提交
  16. 03 11月, 2016 4 次提交
  17. 23 9月, 2016 1 次提交
  18. 22 9月, 2016 1 次提交
  19. 21 9月, 2016 1 次提交
  20. 17 9月, 2016 1 次提交
  21. 15 9月, 2016 5 次提交
  22. 14 9月, 2016 2 次提交
  23. 29 8月, 2016 2 次提交
    • J
      blk-mq: improve layout of blk_mq_hw_ctx · 8d354f13
      Jens Axboe 提交于
      Various cache line optimizations:
      
      - Move delay_work towards the end. It's huge, and we don't use it
        a lot (only SCSI).
      
      - Move the atomic state into the same cacheline as the the dispatch
        list and lock.
      
      - Rearrange a few members to pack it better.
      
      - Shrink the max-order for dispatch accounting from 10 to 7. This
        means that ->dispatched[] and ->run now take up their own
        cacheline.
      
      This shrinks struct blk_mq_hw_ctx down to 8 cachelines.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      8d354f13
    • J
      blk-mq: turn hctx->run_work into a regular work struct · 27489a3c
      Jens Axboe 提交于
      We don't need the larger delayed work struct, since we always run it
      immediately.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      27489a3c
  24. 08 7月, 2016 1 次提交
  25. 06 7月, 2016 1 次提交
  26. 13 4月, 2016 2 次提交