1. 11 12月, 2009 3 次提交
    • M
      dm io: handle empty barriers · 12fc0f49
      Mikulas Patocka 提交于
      Accept empty barriers in dm-io.
      
      dm-io will process empty write barrier requests just like the other
      read/write requests.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      12fc0f49
    • M
      dm io: remove extra bi_io_vec region hack · f1e53987
      Mikulas Patocka 提交于
      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: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      f1e53987
    • M
      dm io: use slab for struct io · 952b3557
      Mikulas Patocka 提交于
      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: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      952b3557
  2. 22 6月, 2009 2 次提交
  3. 03 4月, 2009 1 次提交
    • M
      dm io: make sync_io uninterruptible · b64b6bf4
      Mikulas Patocka 提交于
      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: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      b64b6bf4
  4. 17 3月, 2009 1 次提交
  5. 18 2月, 2009 1 次提交
  6. 29 12月, 2008 1 次提交
    • J
      bio: allow individual slabs in the bio_set · bb799ca0
      Jens Axboe 提交于
      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: NJens Axboe <jens.axboe@oracle.com>
      bb799ca0
  7. 22 10月, 2008 1 次提交
  8. 25 4月, 2008 4 次提交
    • M
      dm: unplug queues in threads · 7ff14a36
      Mikulas Patocka 提交于
      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: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      Acked-by: NJens Axboe <jens.axboe@oracle.com>
      7ff14a36
    • A
      dm: move include files · a765e20e
      Alasdair G Kergon 提交于
      Publish the dm-io, dm-log and dm-kcopyd headers in include/linux.
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      a765e20e
    • H
      dm io: clean interface · 22a1ceb1
      Heinz Mauelshagen 提交于
      Clean up the dm-io interface to prepare for publishing it in include/linux.
      Signed-off-by: NHeinz Mauelshagen <hjm@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      22a1ceb1
    • A
      dm io: rename error to error_bits · e01fd7ee
      Alasdair G Kergon 提交于
      Rename 'error' to 'error_bits' for clarity.
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      e01fd7ee
  9. 29 3月, 2008 1 次提交
  10. 10 10月, 2007 1 次提交
  11. 13 7月, 2007 1 次提交
  12. 10 5月, 2007 4 次提交
  13. 30 4月, 2007 1 次提交
    • J
      [BLOCK] Don't pin lots of memory in mempools · 5972511b
      Jens Axboe 提交于
      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: NJens Axboe <jens.axboe@oracle.com>
      5972511b
  14. 09 12月, 2006 1 次提交
  15. 27 3月, 2006 1 次提交
  16. 09 10月, 2005 1 次提交
  17. 08 9月, 2005 1 次提交
  18. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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