1. 10 Mar, 2011 1 commit
    • Jens Axboe's avatar
      block: kill off REQ_UNPLUG · 721a9602
      Jens Axboe authored
      With the plugging now being explicitly controlled by the
      submitter, callers need not pass down unplugging hints
      to the block layer. If they want to unplug, it's because they
      manually plugged on their own - in which case, they should just
      unplug at will.
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      721a9602
  2. 10 Sep, 2010 1 commit
    • Tejun Heo's avatar
      dm: implement REQ_FLUSH/FUA support for bio-based dm · d87f4c14
      Tejun Heo authored
      This patch converts bio-based dm to support REQ_FLUSH/FUA instead of
      now deprecated REQ_HARDBARRIER.
      
      * -EOPNOTSUPP handling logic dropped.
      
      * Preflush is handled as before but postflush is dropped and replaced
        with passing down REQ_FUA to member request_queues.  This replaces
        one array wide cache flush w/ member specific FUA writes.
      
      * __split_and_process_bio() now calls __clone_and_map_flush() directly
        for flushes and guarantees all FLUSH bio's going to targets are zero
      `  length.
      
      * It's now guaranteed that all FLUSH bio's which are passed onto dm
        targets are zero length.  bio_empty_barrier() tests are replaced
        with REQ_FLUSH tests.
      
      * Empty WRITE_BARRIERs are replaced with WRITE_FLUSHes.
      
      * Dropped unlikely() around REQ_FLUSH tests.  Flushes are not unlikely
        enough to be marked with unlikely().
      
      * Block layer now filters out REQ_FLUSH/FUA bio's if the request_queue
        doesn't support cache flushing.  Advertise REQ_FLUSH | REQ_FUA
        capability.
      
      * Request based dm isn't converted yet.  dm_init_request_based_queue()
        resets flush support to 0 for now.  To avoid disturbing request
        based dm code, dm->flush_error is added for bio based dm while
        requested based dm continues to use dm->barrier_error.
      
      Lightly tested linear, stripe, raid1, snap and crypt targets.  Please
      proceed with caution as I'm not familiar with the code base.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: dm-devel@redhat.com
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      d87f4c14
  3. 07 Aug, 2010 1 commit
    • Christoph Hellwig's avatar
      block: unify flags for struct bio and struct request · 7b6d91da
      Christoph Hellwig authored
      Remove the current bio flags and reuse the request flags for the bio, too.
      This allows to more easily trace the type of I/O from the filesystem
      down to the block driver.  There were two flags in the bio that were
      missing in the requests:  BIO_RW_UNPLUG and BIO_RW_AHEAD.  Also I've
      renamed two request flags that had a superflous RW in them.
      
      Note that the flags are in bio.h despite having the REQ_ name - as
      blkdev.h includes bio.h that is the only way to go for now.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      7b6d91da
  4. 10 Dec, 2009 3 commits
    • Mikulas Patocka's avatar
      dm io: handle empty barriers · 12fc0f49
      Mikulas Patocka authored
      Accept empty barriers in dm-io.
      
      dm-io will process empty write barrier requests just like the other
      read/write requests.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      12fc0f49
    • Mikulas Patocka's avatar
      dm io: remove extra bi_io_vec region hack · f1e53987
      Mikulas Patocka authored
      Remove the hack where we allocate an extra bi_io_vec to store additional
      private data.  This hack prevents us from supporting barriers in
      dm-raid1 without first making another little block layer change.
      Instead of doing that, this patch eliminates the bi_io_vec abuse by
      storing the region number directly in the low bits of bi_private.
      
      We need to store two things for each bio, the pointer to the main io
      structure and, if parallel writes were requested, an index indicating
      which of these writes this bio belongs to.  There can be at most
      BITS_PER_LONG regions - 32 or 64.
      
      The index (region number) was stored in the last (hidden) bio vector and
      the pointer to struct io was stored in bi_private.
      
      This patch now aligns "struct io" on BITS_PER_LONG bytes and stores the
      region number in the low BITS_PER_LONG bits of bi_private.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      f1e53987
    • Mikulas Patocka's avatar
      dm io: use slab for struct io · 952b3557
      Mikulas Patocka authored
      Allocate "struct io" from a slab.
      
      This patch changes dm-io, so that "struct io" is allocated from a slab cache.
      It used to be allocated with kmalloc. Allocating from a slab will be needed
      for the next patch, because it requires a special alignment of "struct io"
      and kmalloc cannot meet this alignment.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      952b3557
  5. 22 Jun, 2009 2 commits
  6. 02 Apr, 2009 1 commit
    • Mikulas Patocka's avatar
      dm io: make sync_io uninterruptible · b64b6bf4
      Mikulas Patocka authored
      If someone sends signal to a process performing synchronous dm-io call,
      the kernel may crash.
      
      The function sync_io attempts to exit with -EINTR if it has pending signal,
      however the structure "io" is allocated on stack, so already submitted io
      requests end up touching unallocated stack space and corrupting kernel memory.
      
      sync_io sets its state to TASK_UNINTERRUPTIBLE, so the signal can't break out
      of io_schedule() --- however, if the signal was pending before sync_io entered
      while (1) loop, the corruption of kernel memory will happen.
      
      There is no way to cancel in-progress IOs, so the best solution is to ignore
      signals at this point.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      b64b6bf4
  7. 16 Mar, 2009 1 commit
  8. 18 Feb, 2009 1 commit
  9. 29 Dec, 2008 1 commit
    • Jens Axboe's avatar
      bio: allow individual slabs in the bio_set · bb799ca0
      Jens Axboe authored
      Instead of having a global bio slab cache, add a reference to one
      in each bio_set that is created. This allows for personalized slabs
      in each bio_set, so that they can have bios of different sizes.
      
      This means we can personalize the bios we return. File systems may
      want to embed the bio inside another structure, to avoid allocation
      more items (and stuffing them in ->bi_private) after the get a bio.
      Or we may want to embed a number of bio_vecs directly at the end
      of a bio, to avoid doing two allocations to return a bio. This is now
      possible.
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      bb799ca0
  10. 21 Oct, 2008 1 commit
  11. 25 Apr, 2008 4 commits
    • Mikulas Patocka's avatar
      dm: unplug queues in threads · 7ff14a36
      Mikulas Patocka authored
      Remove an avoidable 3ms delay on some dm-raid1 and kcopyd I/O.
      
      It is specified that any submitted bio without BIO_RW_SYNC flag may plug the
      queue (i.e. block the requests from being dispatched to the physical device).
      
      The queue is unplugged when the caller calls blk_unplug() function. Usually, the
      sequence is that someone calls submit_bh to submit IO on a buffer. The IO plugs
      the queue and waits (to be possibly joined with other adjacent bios). Then, when
      the caller calls wait_on_buffer(), it unplugs the queue and submits the IOs to
      the disk.
      
      This was happenning:
      
      When doing O_SYNC writes, function fsync_buffers_list() submits a list of
      bios to dm_raid1, the bios are added to dm_raid1 write queue and kmirrord is
      woken up.
      
      fsync_buffers_list() calls wait_on_buffer().  That unplugs the queue, but
      there are no bios on the device queue as they are still in the dm_raid1 queue.
      
      wait_on_buffer() starts waiting until the IO is finished.
      
      kmirrord is scheduled, kmirrord takes bios and submits them to the devices.
      
      The submitted bio plugs the harddisk queue but there is no one to unplug it.
      (The process that called wait_on_buffer() is already sleeping.)
      
      So there is a 3ms timeout, after which the queues on the harddisks are
      unplugged and requests are processed.
      
      This 3ms timeout meant that in certain workloads (e.g. O_SYNC, 8kb writes),
      dm-raid1 is 10 times slower than md raid1.
      
      Every time we submit something asynchronously via dm_io, we must unplug the
      queue actually to send the request to the device.
      
      This patch adds an unplug call to kmirrord - while processing requests, it keeps
      the queue plugged (so that adjacent bios can be merged); when it finishes
      processing all the bios, it unplugs the queue to submit the bios.
      
      It also fixes kcopyd which has the same potential problem. All kcopyd requests
      are submitted with BIO_RW_SYNC.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      Acked-by: default avatarJens Axboe <jens.axboe@oracle.com>
      7ff14a36
    • Alasdair G Kergon's avatar
      dm: move include files · a765e20e
      Alasdair G Kergon authored
      Publish the dm-io, dm-log and dm-kcopyd headers in include/linux.
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      a765e20e
    • Heinz Mauelshagen's avatar
      dm io: clean interface · 22a1ceb1
      Heinz Mauelshagen authored
      Clean up the dm-io interface to prepare for publishing it in include/linux.
      Signed-off-by: default avatarHeinz Mauelshagen <hjm@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      22a1ceb1
    • Alasdair G Kergon's avatar
      dm io: rename error to error_bits · e01fd7ee
      Alasdair G Kergon authored
      Rename 'error' to 'error_bits' for clarity.
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      e01fd7ee
  12. 28 Mar, 2008 1 commit
  13. 10 Oct, 2007 1 commit
  14. 12 Jul, 2007 1 commit
  15. 09 May, 2007 4 commits
  16. 30 Apr, 2007 1 commit
    • Jens Axboe's avatar
      [BLOCK] Don't pin lots of memory in mempools · 5972511b
      Jens Axboe authored
      Currently we scale the mempool sizes depending on memory installed
      in the machine, except for the bio pool itself which sits at a fixed
      256 entry pre-allocation.
      
      There's really no point in "optimizing" this OOM path, we just need
      enough preallocated to make progress. A single unit is enough, lets
      scale it down to 2 just to be on the safe side.
      
      This patch saves ~150kb of pinned kernel memory on a 32-bit box.
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      5972511b
  17. 08 Dec, 2006 1 commit
  18. 26 Mar, 2006 1 commit
  19. 08 Oct, 2005 1 commit
  20. 07 Sep, 2005 1 commit
  21. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4