1. 07 6月, 2008 1 次提交
  2. 19 2月, 2008 2 次提交
    • A
      fs/block_dev.c: remove #if 0'ed code · 86b6c7a7
      Adrian Bunk 提交于
      Commit b2e895db #if 0'ed this code stating:
      
      <--  snip  -->
      
          [PATCH] revert blockdev direct io back to 2.6.19 version
      
          Andrew Vasquez is reporting as-iosched oopses and a 65% throughput
          slowdown due to the recent special-casing of direct-io against
          blockdevs.  We don't know why either of these things are occurring.
      
          The patch minimally reverts us back to the 2.6.19 code for a 2.6.20
          release.
      
      <--  snip  -->
      
      It has since been dead code, and unless someone wants to revive it now
      it's time to remove it.
      
      This patch also makes bio_release_pages() static again and removes the
      ki_bio_count member from struct kiocb, reverting changes that had been
      done for this dead code.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NJens Axboe <axboe@carl.home.kernel.dk>
      86b6c7a7
    • A
      make struct def_blk_aops static · 4c54ac62
      Adrian Bunk 提交于
      This patch makes the needlessly global struct def_blk_aops static.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NJens Axboe <axboe@carl.home.kernel.dk>
      4c54ac62
  3. 15 2月, 2008 2 次提交
  4. 07 2月, 2008 1 次提交
  5. 25 1月, 2008 1 次提交
    • K
      Driver core: convert block from raw kobjects to core devices · edfaa7c3
      Kay Sievers 提交于
      This moves the block devices to /sys/class/block. It will create a
      flat list of all block devices, with the disks and partitions in one
      directory. For compatibility /sys/block is created and contains symlinks
      to the disks.
      
        /sys/class/block
        |-- sda -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
        |-- sda1 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda1
        |-- sda10 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda10
        |-- sda5 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda5
        |-- sda6 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda6
        |-- sda7 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda7
        |-- sda8 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda8
        |-- sda9 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda9
        `-- sr0 -> ../../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0
      
        /sys/block/
        |-- sda -> ../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
        `-- sr0 -> ../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      edfaa7c3
  6. 17 10月, 2007 2 次提交
  7. 10 10月, 2007 1 次提交
  8. 20 7月, 2007 1 次提交
    • P
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt 提交于
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      20c2df83
  9. 17 7月, 2007 3 次提交
  10. 10 7月, 2007 1 次提交
  11. 17 5月, 2007 1 次提交
    • C
      Remove SLAB_CTOR_CONSTRUCTOR · a35afb83
      Christoph Lameter 提交于
      SLAB_CTOR_CONSTRUCTOR is always specified. No point in checking it.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: Michael Halcrow <mhalcrow@us.ibm.com>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Dave Kleikamp <shaggy@austin.ibm.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Mark Fasheh <mark.fasheh@oracle.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Jan Kara <jack@ucw.cz>
      Cc: David Chinner <dgc@sgi.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a35afb83
  12. 09 5月, 2007 1 次提交
  13. 08 5月, 2007 3 次提交
    • C
      slab allocators: Remove SLAB_DEBUG_INITIAL flag · 50953fe9
      Christoph Lameter 提交于
      I have never seen a use of SLAB_DEBUG_INITIAL.  It is only supported by
      SLAB.
      
      I think its purpose was to have a callback after an object has been freed
      to verify that the state is the constructor state again?  The callback is
      performed before each freeing of an object.
      
      I would think that it is much easier to check the object state manually
      before the free.  That also places the check near the code object
      manipulation of the object.
      
      Also the SLAB_DEBUG_INITIAL callback is only performed if the kernel was
      compiled with SLAB debugging on.  If there would be code in a constructor
      handling SLAB_DEBUG_INITIAL then it would have to be conditional on
      SLAB_DEBUG otherwise it would just be dead code.  But there is no such code
      in the kernel.  I think SLUB_DEBUG_INITIAL is too problematic to make real
      use of, difficult to understand and there are easier ways to accomplish the
      same effect (i.e.  add debug code before kfree).
      
      There is a related flag SLAB_CTOR_VERIFY that is frequently checked to be
      clear in fs inode caches.  Remove the pointless checks (they would even be
      pointless without removeal of SLAB_DEBUG_INITIAL) from the fs constructors.
      
      This is the last slab flag that SLUB did not support.  Remove the check for
      unimplemented flags from SLUB.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      50953fe9
    • P
      mm: optimize kill_bdev() · f9a14399
      Peter Zijlstra 提交于
      Remove duplicate work in kill_bdev().
      
      It currently invalidates and then truncates the bdev's mapping.
      invalidate_mapping_pages() will opportunistically remove pages from the
      mapping.  And truncate_inode_pages() will forcefully remove all pages.
      
      The only thing truncate doesn't do is flush the bh lrus.  So do that
      explicitly.  This avoids (very unlikely) but possible invalid lookup
      results if the same bdev is quickly re-issued.
      
      It also will prevent extreme kernel latencies which are observed when
      blockdevs which have a large amount of pagecache are unmounted, by avoiding
      invalidate_mapping_pages() on that path.  invalidate_mapping_pages() has no
      cond_resched (it can be called under spinlock), whereas truncate_inode_pages()
      has one.
      
      [akpm@linux-foundation.org: restore nrpages==0 optimisation]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f9a14399
    • P
      mm: remove destroy_dirty_buffers from invalidate_bdev() · f98393a6
      Peter Zijlstra 提交于
      Remove the destroy_dirty_buffers argument from invalidate_bdev(), it hasn't
      been used in 6 years (so akpm says).
      
      find * -name \*.[ch] | xargs grep -l invalidate_bdev |
      while read file; do
      	quilt add $file;
      	sed -ie 's/invalidate_bdev(\([^,]*\),[^)]*)/invalidate_bdev(\1)/g' $file;
      done
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f98393a6
  14. 21 2月, 2007 1 次提交
    • P
      [PATCH] lockdep: annotate BLKPG_DEL_PARTITION · 6d740cd5
      Peter Zijlstra 提交于
      >=============================================
      >[ INFO: possible recursive locking detected ]
      >2.6.19-1.2909.fc7 #1
      >---------------------------------------------
      >anaconda/587 is trying to acquire lock:
      > (&bdev->bd_mutex){--..}, at: [<c05fb380>] mutex_lock+0x21/0x24
      >
      >but task is already holding lock:
      > (&bdev->bd_mutex){--..}, at: [<c05fb380>] mutex_lock+0x21/0x24
      >
      >other info that might help us debug this:
      >1 lock held by anaconda/587:
      > #0:  (&bdev->bd_mutex){--..}, at: [<c05fb380>] mutex_lock+0x21/0x24
      >
      >stack backtrace:
      > [<c0405812>] show_trace_log_lvl+0x1a/0x2f
      > [<c0405db2>] show_trace+0x12/0x14
      > [<c0405e36>] dump_stack+0x16/0x18
      > [<c043bd84>] __lock_acquire+0x116/0xa09
      > [<c043c960>] lock_acquire+0x56/0x6f
      > [<c05fb1fa>] __mutex_lock_slowpath+0xe5/0x24a
      > [<c05fb380>] mutex_lock+0x21/0x24
      > [<c04d82fb>] blkdev_ioctl+0x600/0x76d
      > [<c04946b1>] block_ioctl+0x1b/0x1f
      > [<c047ed5a>] do_ioctl+0x22/0x68
      > [<c047eff2>] vfs_ioctl+0x252/0x265
      > [<c047f04e>] sys_ioctl+0x49/0x63
      > [<c0404070>] syscall_call+0x7/0xb
      
      Annotate BLKPG_DEL_PARTITION's bd_mutex locking and add a little comment
      clarifying the bd_mutex locking, because I confused myself and initially
      thought the lock order was wrong too.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6d740cd5
  15. 13 2月, 2007 1 次提交
  16. 04 2月, 2007 1 次提交
  17. 23 1月, 2007 2 次提交
  18. 12 1月, 2007 1 次提交
  19. 14 12月, 2006 1 次提交
    • C
      [PATCH] optimize o_direct on block devices · e61c9018
      Chen, Kenneth W 提交于
      Implement block device specific .direct_IO method instead of going through
      generic direct_io_worker for block device.
      
      direct_io_worker() is fairly complex because it needs to handle O_DIRECT on
      file system, where it needs to perform block allocation, hole detection,
      extents file on write, and tons of other corner cases.  The end result is
      that it takes tons of CPU time to submit an I/O.
      
      For block device, the block allocation is much simpler and a tight triple
      loop can be written to iterate each iovec and each page within the iovec in
      order to construct/prepare bio structure and then subsequently submit it to
      the block layer.  This significantly speeds up O_D on block device.
      
      [akpm@osdl.org: small speedup]
      Signed-off-by: NKen Chen <kenneth.w.chen@intel.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Zach Brown <zach.brown@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e61c9018
  20. 09 12月, 2006 7 次提交
  21. 08 12月, 2006 2 次提交
  22. 01 11月, 2006 1 次提交
  23. 31 10月, 2006 2 次提交
  24. 29 10月, 2006 1 次提交