linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
	 Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>
Cc: Mateusz Guzik <mjguzik@gmail.com>,
	linux-fsdevel@vger.kernel.org,  linux-kernel@vger.kernel.org,
	Jeff Layton <jlayton@kernel.org>
Subject: [PATCH RFC] fs: don't force i_version increment when timestamps change
Date: Tue, 27 Aug 2024 10:29:57 -0400	[thread overview]
Message-ID: <20240827-iversion-v1-1-b46a2b612400@kernel.org> (raw)

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@gmail.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
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@kernel.org>


             reply	other threads:[~2024-08-27 14:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-27 14:29 Jeff Layton [this message]
2024-08-27 23:38 ` [PATCH RFC] fs: don't force i_version increment when timestamps change Mateusz Guzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240827-iversion-v1-1-b46a2b612400@kernel.org \
    --to=jlayton@kernel.org \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjguzik@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).