diff options
author | Mateusz Guzik <mjguzik@gmail.com> | 2024-06-24 10:54:02 +0200 |
---|---|---|
committer | Christian Brauner <brauner@kernel.org> | 2024-06-25 11:15:48 +0200 |
commit | 8e3447822d7d8c0f562c6851a7a31e24d1ede55e (patch) | |
tree | e16c35e65568d16c083380d92bfe161127956ae0 /fs/cachefiles/key.c | |
parent | 153216cf7bd50842ffc3d500ea96adeb65db63ef (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