summaryrefslogtreecommitdiff
path: root/fs/cachefiles/key.c
diff options
context:
space:
mode:
authorMateusz Guzik <mjguzik@gmail.com>2024-06-24 10:54:02 +0200
committerChristian Brauner <brauner@kernel.org>2024-06-25 11:15:48 +0200
commit8e3447822d7d8c0f562c6851a7a31e24d1ede55e (patch)
treee16c35e65568d16c083380d92bfe161127956ae0 /fs/cachefiles/key.c
parent153216cf7bd50842ffc3d500ea96adeb65db63ef (diff)
vfs: remove redundant smp_mb for thp handling in do_dentry_open
opening for write performs: if (f->f_mode & FMODE_WRITE) { [snip] smp_mb(); if (filemap_nr_thps(inode->i_mapping)) { [snip] } } filemap_nr_thps on kernels built without CONFIG_READ_ONLY_THP_FOR expands to 0, allowing the compiler to eliminate the entire thing, with exception of the fence (and the branch leading there). So happens required synchronisation between i_writecount and nr_thps changes is already provided by the full fence coming from get_write_access -> atomic_inc_unless_negative, thus the smp_mb instance above can be removed regardless of CONFIG_READ_ONLY_THP_FOR. While I updated commentary in places claiming to match the now-removed fence, I did not try to patch them to act on the compile option. I did not bother benchmarking it, not issuing a spurious full fence in the fast path does not warrant justification from perf standpoint. Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://lore.kernel.org/r/20240624085402.493630-1-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
Diffstat (limited to 'fs/cachefiles/key.c')
0 files changed, 0 insertions, 0 deletions