inode_maybe_inc_iversion will increment the i_version if it has been
queried. We can also set the "force" parameter to force an increment.
When we originally did this, the idea was to set it to force when we
were going to be otherwise updating the inode timestamps anyway --
purely a "might as well" measure.
When we used coarse-grained timestamps exclusively, this would give us
an extra cmpxchg operation roughly every jiffy when a file is under
heavy writes. With the advent of multigrain timestamps however, this can
fire more frequently.
There is no requirement to force an increment to the i_version just
because a timestamp changed, so stop doing it.
Cc: Mateusz Guzik <mjguzik@xxxxxxxxx>
Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
---
I've not tested this other than for compilation, but it should be fine.
Mateusz, does this help your workload at all? There may be other places
where we can just set this to false (maybe even convert some of the
inode_inc_iversion() calls to this.
---
fs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/inode.c b/fs/inode.c
index 10c4619faeef..2abd6317839b 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1962,7 +1962,7 @@ int inode_update_timestamps(struct inode *inode, int flags)
inode_set_mtime_to_ts(inode, now);
updated |= S_MTIME;
}
- if (IS_I_VERSION(inode) && inode_maybe_inc_iversion(inode, updated))
+ if (IS_I_VERSION(inode) && inode_maybe_inc_iversion(inode, false))
updated |= S_VERSION;
} else {
now = current_time(inode);
---
base-commit: 3e9bff3bbe1355805de919f688bef4baefbfd436
change-id: 20240827-iversion-afa53f0a070b
Best regards,
--
Jeff Layton <jlayton@xxxxxxxxxx>
