[PATCH 0/2] XFS buffer cache scalability improvements

[Lucas Stach <dev@lynxeye.de>]

Hi all,

this series scratches my own small itch with XFS, namely scalability of the buffer
cache in metadata intensive workloads. With a large number of cached buffers those
workloads are CPU bound with a significant amount of time spent searching the cache.

The first commit replaces the rbtree used to index the cache with an rhashtable. The
rbtree is a bottleneck in scalability, as the data structure itself is pretty CPU
cache unfriendly. For larger numbers of cached buffers over 80% of the CPU time
is spent waiting on cache misses resulting from the inherent pointer chasing.

rhashtables provide a fast lookup with the ability to have lookups proceed while the
hashtable is being resized. This seems to match the read dominated workload of the
buffer cache index structure pretty well.

The second patch is logical follow up. The rhashtable cache index is protected by
RCU and does not need any additional locking. By switching the buffer cache entries
over to RCU freeing the buffer cache can be operated in a completely lock-free
manner. This should help scalability in the long run.

This series survives at least a xfstests auto group run (though with the scratch
device being a ramdisk) with no regressions and didn't show any problems in my
real world testing (using the patched FS with multiple large git trees) so far.

Regards,
Lucas

Lucas Stach (2):
  xfs: use rhashtable to track buffer cache
  xfs: switch buffer cache entries to RCU freeing

 fs/xfs/xfs_buf.c   | 155 ++++++++++++++++++++++++++++++++++-------------------
 fs/xfs/xfs_buf.h   |   4 +-
 fs/xfs/xfs_linux.h |   1 +
 fs/xfs/xfs_mount.c |   7 ++-
 fs/xfs/xfs_mount.h |   6 ++-
 5 files changed, 114 insertions(+), 59 deletions(-)

-- 
2.7.4