1. 12 Jul, 2011 2 commits
  2. 10 Jul, 2011 1 commit
  3. 08 Jul, 2011 2 commits
    • Shaohua Li's avatar
      block: document blk_plug list access · 316cc67d
      Shaohua Li authored
      I'm often confused why not disable preempt when changing blk_plug list. It
      would be better to add comments here in case others have the similar concerns.
      Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      316cc67d
    • Shaohua Li's avatar
      block: avoid building too big plug list · 55c022bb
      Shaohua Li authored
      When I test fio script with big I/O depth, I found the total throughput drops
      compared to some relative small I/O depth. The reason is the thread accumulates
      big requests in its plug list and causes some delays (surely this depends
      on CPU speed).
      I thought we'd better have a threshold for requests. When a threshold reaches,
      this means there is no request merge and queue lock contention isn't severe
      when pushing per-task requests to queue, so the main advantages of blk plug
      don't exist. We can force a plug list flush in this case.
      With this, my test throughput actually increases and almost equals to small
      I/O depth. Another side effect is irq off time decreases in blk_flush_plug_list()
      for big I/O depth.
      The BLK_MAX_REQUEST_COUNT is choosen arbitarily, but 16 is efficiently to
      reduce lock contention to me. But I'm open here, 32 is ok in my test too.
      Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      55c022bb
  4. 07 Jul, 2011 1 commit
  5. 06 Jul, 2011 1 commit
    • Mike Snitzer's avatar
      block: eliminate potential for infinite loop in blkdev_issue_discard · 0f799603
      Mike Snitzer authored
      Due to the recently identified overflow in read_capacity_16() it was
      possible for max_discard_sectors to be zero but still have discards
      enabled on the associated device's queue.
      
      Eliminate the possibility for blkdev_issue_discard to infinitely loop.
      
      Interestingly this issue wasn't identified until a device, whose
      discard_granularity was 0 due to read_capacity_16 overflow, was consumed
      by blk_stack_limits() to construct limits for a higher-level DM
      multipath device.  The multipath device's resulting limits never had the
      discard limits stacked because blk_stack_limits() will only do so if
      the bottom device's discard_granularity != 0.  This resulted in the
      multipath device's limits.max_discard_sectors being 0.
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      0f799603
  6. 01 Jul, 2011 3 commits
    • Johannes Stezenbach's avatar
      compat_ioctl: fix warning caused by qemu · 390192b3
      Johannes Stezenbach authored
      On Linux x86_64 host with 32bit userspace, running
      qemu or even just "qemu-img create -f qcow2 some.img 1G"
      causes a kernel warning:
      
      ioctl32(qemu-img:5296): Unknown cmd fd(3) cmd(00005326){t:'S';sz:0} arg(7fffffff) on some.img
      ioctl32(qemu-img:5296): Unknown cmd fd(3) cmd(801c0204){t:02;sz:28} arg(fff77350) on some.img
      
      ioctl 00005326 is CDROM_DRIVE_STATUS,
      ioctl 801c0204 is FDGETPRM.
      
      The warning appears because the Linux compat-ioctl handler for these
      ioctls only applies to block devices, while qemu also uses the ioctls on
      plain files.
      Signed-off-by: default avatarJohannes Stezenbach <js@sig21.net>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      390192b3
    • Tejun Heo's avatar
      block: flush MEDIA_CHANGE from drivers on close(2) · 85ef06d1
      Tejun Heo authored
      Currently, only open(2) is defined as the 'clearing' point.  It has
      two roles - first, it's an acknowledgement from userland indicating
      that the event has been received and kernel can clear pending states
      and proceed to generate more events.  Secondly, it's passed on to
      device drivers as a hint indicating that a synchronization point has
      been reached and it might want to take a deeper look at the device.
      
      The latter currently is only used by sr which uses two different
      mechanisms - GET_EVENT_MEDIA_STATUS_NOTIFICATION and TEST_UNIT_READY
      to discover events, where the former is lighter weight and safe to be
      used repeatedly but may not provide full coverage.  Among other
      things, GET_EVENT can't detect media removal while TUR can.
      
      This patch makes close(2) - blkdev_put() - indicate clearing hint for
      MEDIA_CHANGE to drivers.  disk_check_events() is renamed to
      disk_flush_events() and updated to take @mask for events to flush
      which is or'd to ev->clearing and will be passed to the driver on the
      next ->check_events() invocation.
      
      This change makes sr generate MEDIA_CHANGE when media is ejected from
      userland - e.g. with eject(1).
      
      Note: Given the current usage, it seems @clearing hint is needlessly
      complex.  disk_clear_events() can simply clear all events and the hint
      can be boolean @flush.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      85ef06d1
    • Jens Axboe's avatar
      Merge branch 'for-linus' into for-3.1/core · 04bf7869
      Jens Axboe authored
      Conflicts:
      	block/blk-throttle.c
      	block/cfq-iosched.c
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      04bf7869
  7. 30 Jun, 2011 8 commits
  8. 27 Jun, 2011 4 commits
  9. 25 Jun, 2011 5 commits
  10. 24 Jun, 2011 13 commits