1. 10 11月, 2016 1 次提交
    • A
      skd: fix msix error handling · 3bc8492f
      Arnd Bergmann 提交于
      As reported by gcc -Wmaybe-uninitialized, the cleanup path for
      skd_acquire_msix tries to free the already allocated msi-x vectors
      in reverse order, but the index variable may not have been
      used yet:
      
      drivers/block/skd_main.c: In function ‘skd_acquire_irq’:
      drivers/block/skd_main.c:3890:8: error: ‘i’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      This changes the failure path to skip releasing the interrupts
      if we have not started requesting them yet.
      
      Fixes: 180b0ae7 ("skd: use pci_alloc_irq_vectors")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      3bc8492f
  2. 09 11月, 2016 1 次提交
  3. 08 11月, 2016 3 次提交
  4. 07 11月, 2016 2 次提交
    • C
      pktcdvd: don't scribble over the bvec array · feebd568
      Christoph Hellwig 提交于
      Hi Peter, hi Jens,
      
      I've been looking over the multi page bio vec work again recently, and
      one of the stumbling blocks is raw biovec access in the pktcdvd.
      
      The first issue is that it directly sets up the page and offset pointers
      in the biovec just before calling bio_add_page.  As bio_add_page already
      does the setup it's trivial to just switch it to stack variables for the
      arguments.
      
      The second issue is the copy code in pkt_make_local_copy, which
      effectively is an opencoded version of bio_copy_data except that it
      skips pages that already are the same in the ѕource and destination.
      But we look at the only calleer we just set up the bio using bio_add_page
      to point exactly to the page array that pkt_make_local_copy compares,
      so the pages will always be the same and we can just remove this function.
      
      Note that all this is done based on code inspection, I don't have any
      packet writing hardware myself.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      feebd568
    • G
      blk-mq: Always schedule hctx->next_cpu · c02ebfdd
      Gabriel Krisman Bertazi 提交于
      Commit 0e87e58b ("blk-mq: improve warning for running a queue on the
      wrong CPU") attempts to avoid triggering the WARN_ON in
      __blk_mq_run_hw_queue when the expected CPU is dead.  Problem is, in the
      last batch execution before round robin, blk_mq_hctx_next_cpu can
      schedule a dead CPU and also update next_cpu to the next alive CPU in
      the mask, which will trigger the WARN_ON despite the previous
      workaround.
      
      The following patch fixes this scenario by always scheduling the value
      in hctx->next_cpu.  This changes the moment when we round-robin the CPU
      running the hctx, but it really doesn't matter, since it still executes
      BLK_MQ_CPU_WORK_BATCH times in a row before switching to another CPU.
      
      Fixes: 0e87e58b ("blk-mq: improve warning for running a queue on the wrong CPU")
      Signed-off-by: NGabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      c02ebfdd
  5. 06 11月, 2016 1 次提交
    • J
      block: add code to track actual device queue depth · d278d4a8
      Jens Axboe 提交于
      For blk-mq, ->nr_requests does track queue depth, at least at init
      time. But for the older queue paths, it's simply a soft setting.
      On top of that, it's generally larger than the hardware setting
      on purpose, to allow backup of requests for merging.
      
      Fill a hole in struct request with a 'queue_depth' member, that
      drivers can call to more closely inform the block layer of the
      real queue depth.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      Reviewed-by: NJan Kara <jack@suse.cz>
      d278d4a8
  6. 04 11月, 2016 2 次提交
    • S
      blk-mq: immediately dispatch big size request · 600271d9
      Shaohua Li 提交于
      This is corresponding part for blk-mq. Disk with multiple hardware
      queues doesn't need this as we only hold 1 request at most.
      Signed-off-by: NShaohua Li <shli@fb.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      600271d9
    • S
      block: immediately dispatch big size request · 50d24c34
      Shaohua Li 提交于
      Currently block plug holds up to 16 non-mergeable requests. This makes
      sense if the request size is small, eg, reduce lock contention. But if
      request size is big enough, we don't need to worry about lock
      contention. Holding such request makes no sense and it lows the disk
      utilization.
      
      In practice, this improves 10% throughput for my raid5 sequential write
      workload.
      
      The size (128k) is arbitrary right now, but it makes sure lock
      contention is small. This probably could be more intelligent, eg, check
      average request size holded. Since this is mainly for sequential IO,
      probably not worthy.
      
      V2: check the last request instead of the first request, so as long as
      there is one big size request we flush the plug.
      Signed-off-by: NShaohua Li <shli@fb.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      50d24c34
  7. 03 11月, 2016 17 次提交
  8. 01 11月, 2016 13 次提交