1. 17 Apr, 2008 3 commits
  2. 28 Apr, 2008 1 commit
  3. 29 Apr, 2008 1 commit
  4. 17 Apr, 2008 8 commits
  5. 29 Apr, 2008 1 commit
    • Eric Sandeen's avatar
      ext4: reduce mballoc stack usage with noinline_for_stack · 4ddfef7b
      Eric Sandeen authored
      mballoc.c is a whole lot of static functions, which gcc seems to
      really like to inline.
      
      With the changes below, on x86, I can at least get from:
      
      432 ext4_mb_new_blocks
      240 ext4_mb_free_blocks
      208 ext4_mb_discard_group_preallocations
      188 ext4_mb_seq_groups_show
      164 ext4_mb_init_cache
      152 ext4_mb_release_inode_pa
      136 ext4_mb_seq_history_show
      ...
      
      to
      
      220 ext4_mb_free_blocks
      188 ext4_mb_seq_groups_show
      176 ext4_mb_regular_allocator
      164 ext4_mb_init_cache
      156 ext4_mb_new_blocks
      152 ext4_mb_release_inode_pa
      136 ext4_mb_seq_history_show
      124 ext4_mb_release_group_pa
      ...
      
      which still has some big functions in there, but not 432 bytes!
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      4ddfef7b
  6. 30 Apr, 2008 2 commits
  7. 29 Apr, 2008 4 commits
  8. 17 Apr, 2008 1 commit
  9. 29 Apr, 2008 5 commits
  10. 17 Apr, 2008 1 commit
  11. 30 Apr, 2008 1 commit
  12. 17 Apr, 2008 1 commit
    • Hisashi Hifumi's avatar
      ext4: fdatasync should skip metadata writeout when overwriting · 53c550e9
      Hisashi Hifumi authored
      Currently fdatasync is identical to fsync in ext3.
      
      I think fdatasync should skip journal flush in data=ordered and
      data=writeback mode when it overwrites to already-instantiated blocks on
      HDD.  When I_DIRTY_DATASYNC flag is not set, fdatasync should skip journal
      writeout because this indicates only atime or/and mtime updates.
      
      Following patch is the same approach of ext2's fsync code(ext2_sync_file).
      
      I did a performance test using the sysbench.
      
      #sysbench --num-threads=128 --max-requests=50000 --test=fileio --file-total-size=128G
      --file-test-mode=rndwr --file-fsync-mode=fdatasync run
      
      The result on ext3 was:
      
      	-2.6.24
      	Operations performed:  0 Read, 50080 Write, 59600 Other = 109680 Total
      	Read 0b  Written 782.5Mb  Total transferred 782.5Mb  (12.116Mb/sec)
      	  775.45 Requests/sec executed
      
      	Test execution summary:
      	    total time:                          64.5814s
      	    total number of events:              50080
      	    total time taken by event execution: 3713.9836
      	    per-request statistics:
      	         min:                            0.0000s
      	         avg:                            0.0742s
      	         max:                            0.9375s
      	         approx.  95 percentile:         0.2901s
      
      	Threads fairness:
      	    events (avg/stddev):           391.2500/23.26
      	    execution time (avg/stddev):   29.0155/1.99
      
      	-2.6.24-patched
      	Operations performed:  0 Read, 50009 Write, 61596 Other = 111605 Total
      	Read 0b  Written 781.39Mb  Total transferred 781.39Mb  (16.419Mb/sec)
      	1050.83 Requests/sec executed
      
      	Test execution summary:
      	    total time:                          47.5900s
      	    total number of events:              50009
      	    total time taken by event execution: 2934.5768
      	    per-request statistics:
       	         min:                            0.0000s
      	         avg:                            0.0587s
       	         max:                            0.8938s
      	         approx.  95 percentile:         0.1993s
      
      	Threads fairness:
      	    events (avg/stddev):           390.6953/22.64
      	    execution time (avg/stddev):   22.9264/1.17
      
      Filesystem I/O throughput was improved.
      
      Signed-off-by :Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>
      Acked-by: default avatarJan Kara <jack@suse.cz>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      53c550e9
  13. 30 Apr, 2008 1 commit
  14. 17 Apr, 2008 2 commits
    • Josef Bacik's avatar
      jbd2: fix possible journal overflow issues · 1dfc3220
      Josef Bacik authored
      There are several cases where the running transaction can get buffers
      added to its BJ_Metadata list which it never dirtied, which makes its
      t_nr_buffers counter end up larger than its t_outstanding_credits
      counter.
      
      This will cause issues when starting new transactions as while we are
      logging buffers we decrement t_outstanding_buffers, so when
      t_outstanding_buffers goes negative, we will report that we need less
      space in the journal than we actually need, so transactions will be
      started even though there may not be enough room for them.  In the worst
      case scenario (which admittedly is almost impossible to reproduce) this
      will result in the journal running out of space.
      
      The fix is to only refile buffers from the committing transaction to the
      running transactions BJ_Modified list when b_modified is set on that
      journal, which is the only way to be sure if the running transaction has
      modified that buffer.
      
      This patch also fixes an accounting error in journal_forget, it is
      possible that we can call journal_forget on a buffer without having
      modified it, only gotten write access to it, so instead of freeing a
      credit, we only do so if the buffer was modified.  The assert will help
      catch if this problem occurs.  Without these two patches I could hit
      this assert within minutes of running postmark, with them this issue no
      longer arises.
      
      Cc: <linux-ext4@vger.kernel.org>
      Cc: Jan Kara <jack@ucw.cz>
      Signed-off-by: default avatarJosef Bacik <jbacik@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      1dfc3220
    • Josef Bacik's avatar
      jbd2: fix the way the b_modified flag is cleared · 9fc7c63a
      Josef Bacik authored
      Currently at the start of a journal commit we loop through all of the buffers
      on the committing transaction and clear the b_modified flag (the flag that is
      set when a transaction modifies the buffer) under the j_list_lock.
      
      The problem is that everywhere else this flag is modified only under the jbd2
      lock buffer flag, so it will race with a running transaction who could
      potentially set it, and have it unset by the committing transaction.
      
      This is also a big waste, you can have several thousands of buffers that you
      are clearing the modified flag on when you may not need to.  This patch
      removes this code and instead clears the b_modified flag upon entering
      do_get_write_access/journal_get_create_access, so if that transaction does
      indeed use the buffer then it will be accounted for properly, and if it does
      not then we know we didn't use it.
      
      That will be important for the next patch in this series.  Tested thoroughly
      by myself using postmark/iozone/bonnie++.
      
      Cc: <linux-ext4@vger.kernel.org>
      Cc: Jan Kara <jack@ucw.cz>
      Signed-off-by: default avatarJosef Bacik <jbacik@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      9fc7c63a
  15. 29 Apr, 2008 8 commits