]> git.ipfire.org Git - thirdparty/linux.git/commit
fs: track the inode having file locks with a flag in ->i_opflags
authorMateusz Guzik <mjguzik@gmail.com>
Wed, 3 Dec 2025 09:48:37 +0000 (10:48 +0100)
committerChristian Brauner <brauner@kernel.org>
Mon, 15 Dec 2025 13:33:38 +0000 (14:33 +0100)
commit887e97745ec336c2f49b6c0af3c4cc00a5df3211
tree98ee23214c9bcfea4556a378b089a9b2bc71784a
parent1fa4e69a54a250fa17d2afd9c5b54a59329033c1
fs: track the inode having file locks with a flag in ->i_opflags

Opening and closing an inode dirties the ->i_readcount field.

Depending on the alignment of the inode, it may happen to false-share
with other fields loaded both for both operations to various extent.

This notably concerns the ->i_flctx field.

Since most inodes don't have the field populated, this bit can be managed
with a flag in ->i_opflags instead which bypasses the problem.

Here are results I obtained while opening a file read-only in a loop
with 24 cores doing the work on Sapphire Rapids. Utilizing the flag as
opposed to reading ->i_flctx field was toggled at runtime as the benchmark
was running, to make sure both results come from the same alignment.

before: 3233740
after:  3373346 (+4%)

before: 3284313
after:  3518711 (+7%)

before: 3505545
after:  4092806 (+16%)

Or to put it differently, this varies wildly depending on how (un)lucky
you get.

The primary bottleneck before and after is the avoidable lockref trip in
do_dentry_open().

Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://patch.msgid.link/20251203094837.290654-2-mjguzik@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
fs/locks.c
include/linux/filelock.h
include/linux/fs.h