1. 03 3月, 2017 1 次提交
    • J
      blk-mq: ensure that bd->last is always set correctly · 113285b4
      Jens Axboe 提交于
      When drivers are called with a request in blk-mq, blk-mq flags the
      state such that the driver knows if this is the last request in
      this call chain or not. The driver can then use that information
      to defer kicking off IO until bd->last is true. However, with blk-mq
      and scheduling, we need to allocate a driver tag for a request before
      it can be issued. If we fail to allocate such a tag, we could end up
      in the situation where the last request issued did not have
      bd->last == true set. This can then cause a driver hang.
      
      This fixes a hang with virtio-blk, which uses bd->last as a hint
      on whether to kick the queue or not.
      Reported-by: NChris Mason <clm@fb.com>
      Tested-by: NChris Mason <clm@fb.com>
      Reviewed-by: NOmar Sandoval <osandov@fb.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      113285b4
  2. 02 3月, 2017 6 次提交
  3. 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
  4. 18 2月, 2017 2 次提交
  5. 11 2月, 2017 1 次提交
  6. 09 2月, 2017 2 次提交
  7. 03 2月, 2017 1 次提交
  8. 01 2月, 2017 1 次提交
    • J
      blk-mq: don't fail allocating driver tag for stopped hw queue · 12d70958
      Jens Axboe 提交于
      We rely on blk_mq_get_driver_tag() not failing if 'wait' is true,
      but it currently fails in that case if the queue happens to be
      stopped at the time of the call.
      
      We don't need to check for stopped here, it's just assigning
      the tag. If the queue is stopped, we'll handle it when
      attempting to run the queue.
      
      This fixes a stall/crash on flush intensive workloads, where
      we proceed to process a flush that doesn't have a valid tag
      assigned.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      12d70958
  9. 28 1月, 2017 3 次提交
  10. 27 1月, 2017 7 次提交
  11. 25 1月, 2017 1 次提交
  12. 21 1月, 2017 1 次提交
    • J
      blk-mq: allow resize of scheduler requests · 70f36b60
      Jens Axboe 提交于
      Add support for growing the tags associated with a hardware queue, for
      the scheduler tags. Currently we only support resizing within the
      limits of the original depth, change that so we can grow it as well by
      allocating and replacing the existing scheduler tag set.
      
      This is similar to how we could increase the software queue depth with
      the legacy IO stack and schedulers.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      Reviewed-by: NOmar Sandoval <osandov@fb.com>
      70f36b60
  13. 19 1月, 2017 2 次提交
  14. 18 1月, 2017 8 次提交
  15. 12 1月, 2017 1 次提交
  16. 26 12月, 2016 1 次提交
    • T
      ktime: Cleanup ktime_set() usage · 8b0e1953
      Thomas Gleixner 提交于
      ktime_set(S,N) was required for the timespec storage type and is still
      useful for situations where a Seconds and Nanoseconds part of a time value
      needs to be converted. For anything where the Seconds argument is 0, this
      is pointless and can be replaced with a simple assignment.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      8b0e1953
  17. 15 12月, 2016 1 次提交
    • G
      blk-mq: Fix failed allocation path when mapping queues · d1b1cea1
      Gabriel Krisman Bertazi 提交于
      In blk_mq_map_swqueue, there is a memory optimization that frees the
      tags of a queue that has gone unmapped.  Later, if that hctx is remapped
      after another topology change, the tags need to be reallocated.
      
      If this allocation fails, a simple WARN_ON triggers, but the block layer
      ends up with an active hctx without any corresponding set of tags.
      Then, any income IO to that hctx can trigger an Oops.
      
      I can reproduce it consistently by running IO, flipping CPUs on and off
      and eventually injecting a memory allocation failure in that path.
      
      In the fix below, if the system experiences a failed allocation of any
      hctx's tags, we remap all the ctxs of that queue to the hctx_0, which
      should always keep it's tags.  There is a minor performance hit, since
      our mapping just got worse after the error path, but this is
      the simplest solution to handle this error path.  The performance hit
      will disappear after another successful remap.
      
      I considered dropping the memory optimization all together, but it
      seemed a bad trade-off to handle this very specific error case.
      
      This should apply cleanly on top of Jens' for-next branch.
      
      The Oops is the one below:
      
      SP (3fff935ce4d0) is in userspace
      1:mon> e
      cpu 0x1: Vector: 300 (Data Access) at [c000000fe99eb110]
          pc: c0000000005e868c: __sbitmap_queue_get+0x2c/0x180
          lr: c000000000575328: __bt_get+0x48/0xd0
          sp: c000000fe99eb390
         msr: 900000010280b033
         dar: 28
       dsisr: 40000000
        current = 0xc000000fe9966800
        paca    = 0xc000000007e80300   softe: 0        irq_happened: 0x01
          pid   = 11035, comm = aio-stress
      Linux version 4.8.0-rc6+ (root@bean) (gcc version 5.4.0 20160609
      (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.2) ) #3 SMP Mon Oct 10 20:16:53 CDT 2016
      1:mon> s
      [c000000fe99eb3d0] c000000000575328 __bt_get+0x48/0xd0
      [c000000fe99eb400] c000000000575838 bt_get.isra.1+0x78/0x2d0
      [c000000fe99eb480] c000000000575cb4 blk_mq_get_tag+0x44/0x100
      [c000000fe99eb4b0] c00000000056f6f4 __blk_mq_alloc_request+0x44/0x220
      [c000000fe99eb500] c000000000570050 blk_mq_map_request+0x100/0x1f0
      [c000000fe99eb580] c000000000574650 blk_mq_make_request+0xf0/0x540
      [c000000fe99eb640] c000000000561c44 generic_make_request+0x144/0x230
      [c000000fe99eb690] c000000000561e00 submit_bio+0xd0/0x200
      [c000000fe99eb740] c0000000003ef740 ext4_io_submit+0x90/0xb0
      [c000000fe99eb770] c0000000003e95d8 ext4_writepages+0x588/0xdd0
      [c000000fe99eb910] c00000000025a9f0 do_writepages+0x60/0xc0
      [c000000fe99eb940] c000000000246c88 __filemap_fdatawrite_range+0xf8/0x180
      [c000000fe99eb9e0] c000000000246f90 filemap_write_and_wait_range+0x70/0xf0
      [c000000fe99eba20] c0000000003dd844 ext4_sync_file+0x214/0x540
      [c000000fe99eba80] c000000000364718 vfs_fsync_range+0x78/0x130
      [c000000fe99ebad0] c0000000003dd46c ext4_file_write_iter+0x35c/0x430
      [c000000fe99ebb90] c00000000038c280 aio_run_iocb+0x3b0/0x450
      [c000000fe99ebce0] c00000000038dc28 do_io_submit+0x368/0x730
      [c000000fe99ebe30] c000000000009404 system_call+0x38/0xec
      Signed-off-by: NGabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
      Cc: Brian King <brking@linux.vnet.ibm.com>
      Cc: Douglas Miller <dougmill@linux.vnet.ibm.com>
      Cc: linux-block@vger.kernel.org
      Cc: linux-scsi@vger.kernel.org
      Reviewed-by: NDouglas Miller <dougmill@linux.vnet.ibm.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      d1b1cea1