1. 03 12月, 2008 1 次提交
    • T
      block: internal dequeue shouldn't start timer · 53a08807
      Tejun Heo 提交于
      blkdev_dequeue_request() and elv_dequeue_request() are equivalent and
      both start the timeout timer.  Barrier code dequeues the original
      barrier request but doesn't passes the request itself to lower level
      driver, only broken down proxy requests; however, as the original
      barrier code goes through the same dequeue path and timeout timer is
      started on it.  If barrier sequence takes long enough, this timer
      expires but the low level driver has no idea about this request and
      oops follows.
      
      Timeout timer shouldn't have been started on the original barrier
      request as it never goes through actual IO.  This patch unexports
      elv_dequeue_request(), which has no external user anyway, and makes it
      operate on elevator proper w/o adding the timer and make
      blkdev_dequeue_request() call elv_dequeue_request() and add timer.
      Internal users which don't pass the request to driver - barrier code
      and end_that_request_last() - are converted to use
      elv_dequeue_request().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Mike Anderson <andmike@linux.vnet.ibm.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      53a08807
  2. 06 11月, 2008 1 次提交
    • T
      block: add timer on blkdev_dequeue_request() not elv_next_request() · 2920ebbd
      Tejun Heo 提交于
      Block queue supports two usage models - one where block driver peeks
      at the front of queue using elv_next_request(), processes it and
      finishes it and the other where block driver peeks at the front of
      queue, dequeue the request using blkdev_dequeue_request() and finishes
      it.  The latter is more flexible as it allows the driver to process
      multiple commands concurrently.
      
      These two inconsistent usage models affect the block layer
      implementation confusing.  For some, elv_next_request() is considered
      the issue point while others consider blkdev_dequeue_request() the
      issue point.
      
      Till now the inconsistency mostly affect only accounting, so it didn't
      really break anything seriously; however, with block layer timeout,
      this inconsistency hits hard.  Block layer considers
      elv_next_request() the issue point and adds timer but SCSI layer
      thinks it was just peeking and when the request can't process the
      command right away, it's just left there without further processing.
      This makes the request dangling on the timer list and, when the timer
      goes off, the request which the SCSI layer and below think is still on
      the block queue ends up in the EH queue, causing various problems - EH
      hang (failed count goes over busy count and EH never wakes up),
      WARN_ON() and oopses as low level driver trying to handle the unknown
      command, etc. depending on the timing.
      
      As SCSI midlayer is the only user of block layer timer at the moment,
      moving blk_add_timer() to elv_dequeue_request() fixes the problem;
      however, this two usage models definitely need to be cleaned up in the
      future.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      2920ebbd
  3. 17 10月, 2008 2 次提交
  4. 09 10月, 2008 6 次提交
  5. 03 7月, 2008 2 次提交
  6. 28 5月, 2008 1 次提交
  7. 01 5月, 2008 1 次提交
  8. 29 4月, 2008 3 次提交
    • A
      block: Skip I/O merges when disabled · ac9fafa1
      Alan D. Brunelle 提交于
      The block I/O + elevator + I/O scheduler code spend a lot of time trying
      to merge I/Os -- rightfully so under "normal" circumstances. However,
      if one were to know that the incoming I/O stream was /very/ random in
      nature, the cycles are wasted.
      
      This patch adds a per-request_queue tunable that (when set) disables
      merge attempts (beyond the simple one-hit cache check), thus freeing up
      a non-trivial amount of CPU cycles.
      Signed-off-by: NAlan D. Brunelle <alan.brunelle@hp.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      ac9fafa1
    • A
      block/elevator.c:elv_rq_merge_ok() mustn't be inline · 72ed0bf6
      Adrian Bunk 提交于
      This patch fixes the following build error with UML and gcc 4.3:
      
      <--  snip  -->
      
      ...
        CC      block/elevator.o
      /home/bunk/linux/kernel-2.6/git/linux-2.6/block/elevator.c: In function ‘elv_merge’:
      /home/bunk/linux/kernel-2.6/git/linux-2.6/block/elevator.c:73: sorry, unimplemented: inlining failed in call to ‘elv_rq_merge_ok’: function body not available
      /home/bunk/linux/kernel-2.6/git/linux-2.6/block/elevator.c:103: sorry, unimplemented: called from here
      /home/bunk/linux/kernel-2.6/git/linux-2.6/block/elevator.c:73: sorry, unimplemented: inlining failed in call to ‘elv_rq_merge_ok’: function body not available
      /home/bunk/linux/kernel-2.6/git/linux-2.6/block/elevator.c:495: sorry, unimplemented: called from here
      make[2]: *** [block/elevator.o] Error 1
      make[1]: *** [block] Error 2
      
      <--  snip  -->
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      72ed0bf6
    • N
      block: make queue flags non-atomic · 75ad23bc
      Nick Piggin 提交于
      We can save some atomic ops in the IO path, if we clearly define
      the rules of how to modify the queue flags.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      75ad23bc
  9. 19 2月, 2008 1 次提交
  10. 01 2月, 2008 1 次提交
  11. 28 1月, 2008 1 次提交
    • J
      block: implement drain buffers · fa0ccd83
      James Bottomley 提交于
      These DMA drain buffer implementations in drivers are pretty horrible
      to do in terms of manipulating the scatterlist.  Plus they're being
      done at least in drivers/ide and drivers/ata, so we now have code
      duplication.
      
      The one use case for this, as I understand it is AHCI controllers doing
      PIO mode to mmc devices but translating this to DMA at the controller
      level.
      
      So, what about adding a callback to the block layer that permits the
      adding of the drain buffer for the problem devices.  The idea is that
      you'd do this in slave_configure after you find one of these devices.
      
      The beauty of doing it in the block layer is that it quietly adds the
      drain buffer to the end of the sg list, so it automatically gets mapped
      (and unmapped) without anything unusual having to be done to the
      scatterlist in driver/scsi or drivers/ata and without any alteration to
      the transfer length.
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      fa0ccd83
  12. 25 1月, 2008 3 次提交
  13. 18 12月, 2007 1 次提交
  14. 20 10月, 2007 1 次提交
  15. 16 10月, 2007 2 次提交
  16. 13 10月, 2007 1 次提交
  17. 24 7月, 2007 1 次提交
  18. 18 7月, 2007 1 次提交
  19. 10 7月, 2007 1 次提交
  20. 30 4月, 2007 1 次提交
  21. 27 3月, 2007 1 次提交
  22. 12 2月, 2007 2 次提交
  23. 24 1月, 2007 1 次提交
    • L
      [PATCH] elevator: move clearing of unplug flag earlier · 95543179
      Linas Vepstas 提交于
      A flag was recently added to the elevator code to avoid
      performing an unplug when reuests are being re-queued.
      The goal of this flag was to avoid a deep recursion that
      can occur when re-queueing requests after a SCSI device/host
      reset.  See http://lkml.org/lkml/2006/5/17/254
      
      However, that fix added the flag near the bottom of a case
      statement, where an earlier break (in an if statement) could
      transport one out of the case, without setting the flag.
      This patch sets the flag earlier in the case statement.
      
      I re-discovered the deep recursion recently during testing;
      I was told that it was a known problem, and the fix to it was
      in the kernel I was testing. Indeed it was ... but it didn't
      fix the bug. With the patch below, I no longer see the bug.
      
      Signed-off by: Linas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      95543179
  24. 22 12月, 2006 1 次提交
  25. 20 12月, 2006 1 次提交
    • J
      [PATCH] cfq-iosched: don't allow sync merges across queues · da775265
      Jens Axboe 提交于
      Currently we allow any merge, even if the io originates from different
      processes. This can cause really bad starvation and unfairness, if those
      ios happen to be synchronous (reads or direct writes).
      
      So add a allow_merge hook to the io scheduler ops, so an io scheduler can
      help decide whether a bio/process combination may be merged with an
      existing request.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      da775265
  26. 01 12月, 2006 1 次提交
  27. 12 10月, 2006 1 次提交