1. 13 5月, 2011 13 次提交
  2. 12 5月, 2011 1 次提交
  3. 06 5月, 2011 3 次提交
  4. 28 4月, 2011 1 次提交
  5. 27 4月, 2011 2 次提交
    • K
      xen/blkback: Stick REQ_SYNC on WRITEs to deal with CFQ I/O scheduler. · 013c3ca1
      Konrad Rzeszutek Wilk 提交于
      If one runs a simple fio request with random read/write with a
      20%/80% ratio, the numbers are incredibly bad when using the CFQ scheduler.
      
      IOmeter       |       |      |          |
      64K, randrw   |  NOOP | CFQ  | deadline |
      randrwmix=80  |       |      |          |
      --------------+-------+------+----------+
      blkback       |103/27 |32/10 | 102/27   |
      --------------+-------+------+----------+
      QEMU qdisk    |103/27 |102/27| 102/27   |
      
      The problem as explained by Vivek Goyal was:
      
      ".. that difference is that sync vs async requests. In the case of
      a kernel thread submitting IO, [..] all the WRITES might be being
      considered as async and will go in a different queue. If you mix those
      with some READS, they are always sync and will go in differnet queue.
      In presence of sync queue, CFQ will idle and choke up WRITES in
      an attempt to improve latencies of READs.
      
      In case of AIO [note: this is what QEMU qdisk is doing] , [..]
      it is direct IO and both READS and WRITES will be considered SYNC
      and will go in a single queue and no choking of WRITES will take place."
      
      The solution is quite simple, tack on REQ_SYNC (which is
      what the WRITE_ODIRECT macro points to) and the numbers go
      back up.
      
      Suggested-by: Vivek Goyal <vgoyal@redhat.com
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      013c3ca1
    • K
      xen/blkback: Move the plugging/unplugging to a higher level. · 97961ef4
      Konrad Rzeszutek Wilk 提交于
      We used to the plug/unplug on the submit_bio. But that means
      if within a stream of WRITE, WRITE, WRITE,...,WRITE we have
      one READ, it could stall the pipeline (as the 'submio_bio'
      could trigger the unplug_fnc to be called and stall/sync
      when doing the READ). Instead we want to move the unplugging
      when the whole (or as a much as possible) ring buffer has been
      processed. This also eliminates us doing plug/unplug for
      each request.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      97961ef4
  6. 20 4月, 2011 4 次提交
  7. 19 4月, 2011 1 次提交
  8. 31 3月, 2011 1 次提交
  9. 28 3月, 2011 1 次提交
    • L
      drbd: fix up merge error · 7e599e6e
      Linus Torvalds 提交于
      In commit 95a0f10c ("drbd: store in-core bitmap little endian,
      regardless of architecture") drbd had made the sane choice to use
      little-endian bitmap functions everywhere.  However, it used the
      horrible old functions names from <asm-generic/bitops/le.h>, that were
      never really meant to be exported.
      
      In the meantime, things got cleaned up, and in commit c4945b9e
      ("asm-generic: rename generic little-endian bitops functions") we
      renamed the LE bitops to something sane, exactly so that they could be
      used in random code without people gouging their eyes out when seeing
      the crazy jumble of letters that were the old internal names.
      
      As a result the drbd thing merged cleanly (commit 8d49a775: "Merge
      branch 'for-2.6.39/drivers' of git://git.kernel.dk/linux-2.6-block"),
      since there was no data conflict - but the end result obviously doesn't
      actually compile.
      Reported-and-tested-by: NIngo Molnar <mingo@elte.hu>
      Cc: Jens Axboe <jaxboe@fusionio.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7e599e6e
  10. 24 3月, 2011 1 次提交
    • B
      cciss: fix lost command issue · 1ddd5049
      Bud Brown 提交于
      Under certain workloads a command may seem to get lost. IOW, the Smart Array
      thinks all commands have been completed but we still have commands in our
      completion queue. This may lead to system instability, filesystems going
      read-only, or even panics depending on the affected filesystem. We add an
      extra read to force the write to complete.
      
      Testing shows this extra read avoids the problem.
      Signed-off-by: NMike Miller <mike.miller@hp.com>
      Cc: stable@kernel.org
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      1ddd5049
  11. 23 3月, 2011 1 次提交
  12. 17 3月, 2011 2 次提交
  13. 12 3月, 2011 8 次提交
  14. 10 3月, 2011 1 次提交