[RFC PATCH] ext4: cacheline-align inode cache to avoid false sharing

JonasZhou-oc posted 1 patch 1 month ago
fs/ext4/super.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
[RFC PATCH] ext4: cacheline-align inode cache to avoid false sharing
Posted by JonasZhou-oc 1 month ago
struct ext4_inode_info embeds struct inode, but ext4_inode_cache does
not request cache-line alignment.  On the tested x86-64 build,
struct ext4_inode_info is 1072 bytes, so consecutive objects can start
at different offsets within a 64-byte cache line.

The embedded inode starts at offset 232, with i_ctime_nsec, i_blkbits,
i_state, and i_rwsem at offsets 352, 366, 376, and 384, respectively.
When the containing object is not cache-line aligned, inode metadata
and i_rwsem can occupy the same cache line.  Metadata updates then
invalidate the line used by CPUs contending on i_rwsem.

Add SLAB_HWCACHE_ALIGN to ext4_inode_cache.  This makes the containing
objects start at cache-line boundaries and, with the tested layout,
places i_rwsem at the start of a cache line separate from the preceding
metadata.

Tests were run on Linux 7.2 on a two-socket Intel Xeon Silver 4208
system with 16 CPUs, SMT disabled, and the frequency fixed at 2 GHz.
Ten normal-mode runs of each zjhbench workload gave:

                         before          after         change
  unixbench.fstime       488330.6       543996.2       +11.40%
  unixbench.fsdisk      1396385.0      1501352.5        +7.52%

On this build, the slab allocation size grows from 1072 to 1088 bytes,
an increase of 16 bytes (1.49%) per ext4 inode.

RFC questions:

1. Is using SLAB_HWCACHE_ALIGN for ext4_inode_cache acceptable when
   the measured benefit depends on the current struct inode layout?

2. Would it be preferable to enable the alignment only when
   vfs_inode.i_rwsem is naturally cache-line aligned within
   struct ext4_inode_info, rather than enabling it unconditionally?

3. Should this false sharing instead be addressed in the generic VFS
   inode layout, despite the significantly larger memory and
   cross-filesystem impact?

4. What additional workloads or configuration coverage would be
   required before this could be considered as a non-RFC patch?

Link: https://lore.kernel.org/linux-fsdevel/CAGudoHFgtM8Px4mRNM_fsmi3=vAyCMPC3FBCzk5uE7ma7fdbdQ@mail.gmail.com/
Signed-off-by: JonasZhou <jonaszhou-oc@zhaoxin.com>
---
 fs/ext4/super.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 245f67d10ded..11090fca1613 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1510,7 +1510,8 @@ static int __init init_inodecache(void)
 	ext4_inode_cachep = kmem_cache_create("ext4_inode_cache",
 				sizeof(struct ext4_inode_info),
 				&args,
-				SLAB_RECLAIM_ACCOUNT | SLAB_ACCOUNT);
+				SLAB_RECLAIM_ACCOUNT | SLAB_ACCOUNT |
+				SLAB_HWCACHE_ALIGN);
 
 	if (ext4_inode_cachep == NULL)
 		return -ENOMEM;
-- 
2.43.0