1. 06 Dec, 2012 2 commits
    • Bart Van Assche's avatar
      block: Let blk_drain_queue() caller obtain the queue lock · 807592a4
      Bart Van Assche authored
      Let the caller of blk_drain_queue() obtain the queue lock to improve
      readability of the patch called "Avoid that request_fn is invoked on
      a dead queue".
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Cc: James Bottomley <JBottomley@Parallels.com>
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Chanho Min <chanho.min@lge.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      807592a4
    • Bart Van Assche's avatar
      block: Rename queue dead flag · 3f3299d5
      Bart Van Assche authored
      QUEUE_FLAG_DEAD is used to indicate that queuing new requests must
      stop. After this flag has been set queue draining starts. However,
      during the queue draining phase it is still safe to invoke the
      queue's request_fn, so QUEUE_FLAG_DYING is a better name for this
      flag.
      
      This patch has been generated by running the following command
      over the kernel source tree:
      
      git grep -lEw 'blk_queue_dead|QUEUE_FLAG_DEAD' |
          xargs sed -i.tmp -e 's/blk_queue_dead/blk_queue_dying/g'      \
              -e 's/QUEUE_FLAG_DEAD/QUEUE_FLAG_DYING/g';                \
      sed -i.tmp -e "s/QUEUE_FLAG_DYING$(printf \\t)*5/QUEUE_FLAG_DYING$(printf \\t)5/g" \
          include/linux/blkdev.h;                                       \
      sed -i.tmp -e 's/ DEAD/ DYING/g' -e 's/dead queue/a dying queue/' \
          -e 's/Dead queue/A dying queue/' block/blk-core.c
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Cc: James Bottomley <JBottomley@Parallels.com>
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Chanho Min <chanho.min@lge.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      3f3299d5
  2. 05 Dec, 2012 1 commit
  3. 10 Nov, 2012 1 commit
  4. 09 Nov, 2012 1 commit
    • Shaohua Li's avatar
      block: recursive merge requests · bee0393c
      Shaohua Li authored
      In a workload, thread 1 accesses a, a+2, ..., thread 2 accesses a+1, a+3,....
      When the requests are flushed to queue, a and a+1 are merged to (a, a+1), a+2
      and a+3 too to (a+2, a+3), but (a, a+1) and (a+2, a+3) aren't merged.
      
      If we do recursive merge for such interleave access, some workloads throughput
      get improvement. A recent worload I'm checking on is swap, below change
      boostes the throughput around 5% ~ 10%.
      Signed-off-by: default avatarShaohua Li <shli@fusionio.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      bee0393c
  5. 06 Nov, 2012 1 commit
    • Shaohua Li's avatar
      block CFQ: avoid moving request to different queue · 3d106fba
      Shaohua Li authored
      request is queued in cfqq->fifo list. Looks it's possible we are moving a
      request from one cfqq to another in request merge case. In such case, adjusting
      the fifo list order doesn't make sense and is impossible if we don't iterate
      the whole fifo list.
      
      My test does hit one case the two cfqq are different, but didn't cause kernel
      crash, maybe it's because fifo list isn't used frequently. Anyway, from the
      code logic, this is buggy.
      
      I thought we can re-enable the recusive merge logic after this is fixed.
      Signed-off-by: default avatarShaohua Li <shli@fusionio.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      3d106fba
  6. 04 Nov, 2012 1 commit
  7. 03 Nov, 2012 15 commits
  8. 02 Nov, 2012 18 commits