[PATCH 0/7] kill-the-bkl/reiserfs performances updates

[Frederic Weisbecker]

Hi Al, everyone,

This patchset is the result of some lock tracing and analysis.

After doing a dbench test on SMP (2 CPUS) with 100 procs during
about 300 secs, I get the following throughput:

With the bkl:
	40 MB/s
With the write lock before this patchset:
	31 MB/s
With the write lock after this patchset:
	36 MB/s

There is still some work to do but it's a good progress.
It seems to depend on the remaining disk space, sometimes I reach
almost the same performances, sometimes it's lower.

For those who want to test it against -rc4, you can pull on the tree
described below, it's a migration of the reiserfs work that was done
in Ingo's tip:core/kill-the-bkl + this patchset.

Thanks,
Frederic.

The following changes since commit e26767ea29f0eb3271e03ba5355c645e2b39939f:
  Frederic Weisbecker (1):
        kill-the-BKL/reiserfs: release the write lock on flush_commit_list()

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
	reiserfs/kill-the-bkl

Frederic Weisbecker (7):
      kill-the-BKL/reiserfs: add reiserfs_cond_resched()
      kill-the-bkl/reiserfs: conditionaly release the write lock on fs_changed()
      kill-the-bkl/reiserfs: lock only once on reiserfs_get_block()
      kill-the-bkl/reiserfs: don't hold the write recursively in reiserfs_lookup()
      kill-the-bkl/reiserfs: reduce number of contentions in search_by_key()
      kill-the-bkl/reiserfs: factorize the locking in reiserfs_write_end()
      kill-the-bkl/reiserfs: use mutex_lock in reiserfs_mutex_lock_safe

 fs/reiserfs/inode.c         |   44 +++++++++++++++++++++++++-----------------
 fs/reiserfs/journal.c       |    8 ++----
 fs/reiserfs/namei.c         |   15 ++++++++++---
 fs/reiserfs/stree.c         |   12 ++++++++++-
 include/linux/reiserfs_fs.h |   17 +++++++++++++--
 5 files changed, 65 insertions(+), 31 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/