1. 08 2月, 2006 8 次提交
  2. 07 2月, 2006 2 次提交
  3. 06 2月, 2006 5 次提交
    • A
      [PATCH] jbd: fix transaction batching · fe1dcbc4
      Andrew Morton 提交于
      Ben points out that:
      
        When writing files out using O_SYNC, jbd's 1 jiffy delay results in a
        significant drop in throughput as the disk sits idle.  The patch below
        results in a 4-5x performance improvement (from 6.5MB/s to ~24-30MB/s on my
        IDE test box) when writing out files using O_SYNC.
      
      So optimise the batching code by omitting it entirely if the process which is
      doing a sync write is the same as the one which did the most recent sync
      write.  If that's true, we're unlikely to get any other processes joining the
      transaction.
      
      (Has been in -mm for ages - it took me a long time to get on to performance
      testing it)
      
      Numbers, on write-cache-disabled IDE:
      
      /usr/bin/time -p synctest -n 10 -uf -t 1 -p 1 dir-name
      
      Unpatched:
      	40 seconds
      Patched:
      	35 seconds
      Batching disabled:
      	35 seconds
      
      This is the problematic single-process-doing-fsync case.  With multiple
      fsyncing processes the numbers are AFACIT unaltered by the patch.
      
      Aside: performance testing and instrumentation shows that the transaction
      batching almost doesn't help (testing with synctest -n 1 -uf -t 100 -p 10
      dir-name on non-writeback-caching IDE).  This is because by the time one
      process is running a synchronous commit, a bunch of other processes already
      have a transaction handle open, so they're all going to batch into the same
      transaction anyway.
      
      The batching seems to offer maybe 5-10% speedup with this workload, but I'm
      pretty sure it was more important than that when it was first developed 4-odd
      years ago...
      
      Cc: "Stephen C. Tweedie" <sct@redhat.com>
      Cc: Benjamin LaHaise <bcrl@kvack.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fe1dcbc4
    • A
      [PATCH] reiserfs_get_acl() build fix · bc5e483d
      Andrew Morton 提交于
      With CONFIG_REISERFS_FS_XATTR=y, CONFIG_REISERFS_FS_POSIX_ACL=n:
      
      fs/reiserfs/xattr.c: In function `reiserfs_check_acl':
      fs/reiserfs/xattr.c:1330: called object is not a function
      
      Cc: Chris Mason <mason@suse.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bc5e483d
    • P
      [PATCH] pktcdvd: Allow larger packets · 5c55ac9b
      Phillip Susi 提交于
      The pktcdvd driver uses a compile time macro constant to define the maximum
      supported packet length.  I changed this from 32 sectors to 128 sectors
      because that allows over 100 MB of additional usable space on a 700 MB cdrw,
      and increases throughput.
      
      Note that you need a modified cdrwtool program that can format a CDRW disc
      with larger packets to benefit from this change.
      Signed-off-by: NPeter Osterlund <petero2@telia.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5c55ac9b
    • P
      [PATCH] pktcdvd: Don't waste kernel memory · e1bc89bc
      Peter Osterlund 提交于
      Allocate memory for read-gathering at open time, when it is known just how
      much memory is needed.  This avoids wasting kernel memory when the real packet
      size is smaller than the maximum packet size supported by the driver.  This is
      always the case when using DVD discs.
      Signed-off-by: NPeter Osterlund <petero2@telia.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e1bc89bc
    • P
      [PATCH] pktcdvd: Fix overflow for discs with large packets · a460ad62
      Phillip Susi 提交于
      The pktcdvd driver was using an 8 bit field to store the packet length
      obtained from the disc track info.  This causes it to overflow packet length
      values of 128KB or more.  I changed the field to 32 bits to fix this.
      
      The pktcdvd driver defaulted to its maximum allowed packet length when it
      detected a 0 in the track info field.  I changed this to fail the operation
      and refuse to access the media.  This seems more sane than attempting to
      access it with a value that almost certainly will not work.
      Signed-off-by: NPeter Osterlund <petero2@telia.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a460ad62
  4. 05 2月, 2006 2 次提交
  5. 04 2月, 2006 17 次提交
  6. 03 2月, 2006 1 次提交
  7. 02 2月, 2006 5 次提交