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 -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
