On Tue, Oct 18, 2016 at 10:14:12PM +0200, Lucas Stach wrote: > On filesystems with a lot of metadata and in metadata intensive workloads > xfs_buf_find() is showing up at the top of the CPU cycles trace. Most of > the CPU time is spent on CPU cache misses while traversing the rbtree. > > As the buffer cache does not need any kind of ordering, but fast lookups > a hashtable is the natural data structure to use. The rhashtable > infrastructure provides a self-scaling hashtable implementation and > allows lookups to proceed while the table is going through a resize > operation. > > This reduces the CPU-time spent for the lookups to 1/3 even for small > filesystems with a relatively small number of cached buffers, with > possibly much larger gains on higher loaded filesystems. > > The minimum size of 4096 buckets was chosen as it was the size of the > xfs buffer cache hash before it was converted to an rbtree. > > Signed-off-by: Lucas Stach <dev@xxxxxxxxxx> This fails to compile on CONFIG_XFS_DEBUG=y kernels due to various ASSERT statements not being updated appropriately. When making XFS changes to core infrastructure like this, it is highly recommended that you use CONFIG_XFS_DEBUG=y so that it catches mistakes and assumptions that your changes violate at runtime.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
