From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0002C7618E for ; Mon, 24 Apr 2023 15:11:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 179A46B0075; Mon, 24 Apr 2023 11:11:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 12B896B0078; Mon, 24 Apr 2023 11:11:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F33BE6B007B; Mon, 24 Apr 2023 11:11:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E47D16B0075 for ; Mon, 24 Apr 2023 11:11:12 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B25B1140255 for ; Mon, 24 Apr 2023 15:11:12 +0000 (UTC) X-FDA: 80716622784.22.A3396EF Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id 2002440022 for ; Mon, 24 Apr 2023 15:11:09 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="QY/s19LP"; spf=pass (imf17.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682349070; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=z0cDMMBmfyOuSaPUQ9JkARR0KAX1KbC3O4OvG6dmtRA=; b=ZMTVNWOuRPVazj5QUi9z+8eHvDhX7VqBmKikvIWQHwDpcye890FKPBjSeCAkQMFqnL70YG qJfN1VdnUVF1g447/tFQ4g1FYPJMl0LeEIQmj4MkiCSDyuQ7BjFxx64NSNyXWGjJ45k88+ 5PDyftBYo880MNdLTYCDRDPZDfv0HWw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682349070; a=rsa-sha256; cv=none; b=yf21Luhesw3mpIpFUzBu1f0326xMYjeDmUnExKTuujri38RjISy5uHw58FRmngV3ifvSzp hJj9zovYLGNwb43S8RH/IEN3g8XAEur8nWa1PZernYCxt815rnsawwCyIH8C1o7aTh+9FT C1OlDqByETdQhTfvcYHCAVgMH/0fU4A= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="QY/s19LP"; spf=pass (imf17.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F183A625BA; Mon, 24 Apr 2023 15:11:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14CBCC433D2; Mon, 24 Apr 2023 15:11:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682349068; bh=BFICM1CCZSEV0CqhIoh8RfzYeucDNgED2DkWd9uMVU0=; h=From:To:Cc:Subject:Date:From; b=QY/s19LPfb6Yval8CT7YXWWpNjgYofRf1ovQPgyZFkAvrNZdW4hIQNwncYqLZHNDg qlms0kvj+yvkfrF5FnD35+4mRcV8QGMckmEDeXf38J8Oq5UShVplyfZ7g47/fZiw4J iii3gaZ8bRfPupC8JjQ2uuUBxwUWMrrYmF4AcRiwAOHLzIA8stz7QEr2JUYyyBRLQE h5pkw1zMZNvASVHeJHqAFnBBuMvoVvSyxnQFJmVnOe0biW9HPJl3Fu/3U/Wgq743RA KmPM/JK8Kyo/1YyvdBWrWvHhuouHyWtmwCkag1bmif5iJz2gWwTXaCF/yDgPC7xmbo zpcY+af+OaXDg== From: Jeff Layton To: Alexander Viro , Christian Brauner , "Darrick J. Wong" , Hugh Dickins , Andrew Morton , Dave Chinner , Chuck Lever Cc: Jan Kara , Amir Goldstein , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org Subject: [PATCH v2 0/3] fs: multigrain timestamps Date: Mon, 24 Apr 2023 11:11:01 -0400 Message-Id: <20230424151104.175456-1-jlayton@kernel.org> X-Mailer: git-send-email 2.40.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 2002440022 X-Rspamd-Server: rspam09 X-Stat-Signature: np38m3f7qfxa5wofohchaefhtdg45ufz X-HE-Tag: 1682349069-297900 X-HE-Meta: U2FsdGVkX1+4Kh/7pUnWUpL2JKtVZAT24v+HQaC3AOt+3l4UoBF9lD9mWOaEybV1jSGIAsoduK+zdbofKo8jDXpOYqJKn3aVP2fxicNq5nW1HqpJBxCekZ/WITAZVy7dDA2rLw5wua7YUR9b01160Yhi6dPvXJy8pr0Dx3fxIqHagScfjZcYF1faeNGI3FlNA+rHgfoo6yiR2lBrb5u54DA8UaFOlThJ1fxhJREr6zGC9c2oyK2XL4VWl75niT2jVYpPIhgmllsnGtnPeU+hfFbjqRDG05HpIQRzcUh7UnvzEDwOy/0nk05BNcM5f4XaPMoMBfONY8N3E5/3of8iQ+N+Zs4JKR6hJ+HuX1ebh1Y09wANMjVNMhgYKonGSRFocdcsuDecaGh7JllvnjXWhHIZbzX1S07umFIDX24VFiYrgJ5TXFAsOOUfyXuLCFAt52WUAC0Jj7iUWAVnfHzaPdds8CgLjGEceH7B4a9oSSFdRKIRjAKOlxX0+Kxa3LF0Y6eVz4oLgmsBcGtqksIPdRTy4QEQqKJ2jtAwg3KzxTDQT+AJQLFko184p2nvT/l1ASFFkxYBnWoe5ZbzH+jzrYhqLd/LzN/hGiAfFfXZjq61lilsMHZvnfgvDZVXhxGrUnVTM4WZ/j4FIgeyw2ow+fYuP7moARE+uUGyddPaHtYQY7dOhILcASZNuEXXoR6jzCefS46LAVS9vBEOgmIARoPbSWMSD3tFJDoSAtsIZVvxo7MLV6pvoLBV9NIfAl4I1Wss+4Gl+Z2tIoXi+cKemctPtwLUpnyR3u6GuwvULmRkNcDR1gzx2adR43bV4zf7T4GH/hfg1MR1mRnBBm47j2bxUEjTiz4v/d3TPq8AFUqXW/aaaDjl+Z0RDyByKI+0BVCgcpeAoX/74oaDdSbEZ1zKge5w1G8Y9p/i3urmk86ILFSuigWc/LHWkvJmVugRsKNm9GCwiYczQJ1qvns kZy1WCFg 72CyLXH68FnRbWdFHbdicBwtiN2lZtCYg2fEWmFtektZvOUvYdVzvavCvDmzYBNsUEuirqAUR3xXeIOFMXS6pvehIRDrSxjgOYWEif1IvM/xlWK8M2FsAb1dlkjwGX7jgYSORVHkU9YyIQtacRnAO4uBDyMqdg760I6eQPFQ1FQalNSkRLDtu8fD2eKJq/+m0mvR4DcW5U84SL5G+dpGNk0DRENZKlV6ahCB5v7l52KyzSSzr70wwzJJPHlhenDeZF9Gb0IoG80qb0LDqWsLzbmpu6A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: A few weeks ago, during one of the discussions around i_version, Dave Chinner wrote this: "You've missed the part where I suggested lifting the "nfsd sampled i_version" state into an inode state flag rather than hiding it in the i_version field. At that point, we could optimise away the secondary ctime updates just like you are proposing we do with the i_version updates. Further, we could also use that state it to decide whether we need to use high resolution timestamps when recording ctime updates - if the nfsd has not sampled the ctime/i_version, we don't need high res timestamps to be recorded for ctime...." While I don't think we can practically optimize away ctime updates like we do with i_version, I do like the idea of using this scheme to indicate when we need to use a high-res timestamp. This patchset is a second attempt at implementing this. The main difference with this set is that it uses the lowest-order bit of the tv_nsec field as the flag instead of using an i_state flag. This also allows us to use atomic ops instead of a spinlock. With this, the patchset also contains a new opt-in mechanism: You must set a SB_MULTIGRAIN_TS flag in the superblock, and also raise your sb->s_time_gran to at least 2. The first patch adds the necessary infrastructure, and the last two patches convert tmpfs and xfs to use it. If this looks good, I'll start embarking on converting other filesystems to this scheme as well. Comments and suggestions welcome! Jeff Layton (3): fs: add infrastructure for multigrain inode i_m/ctime shmem: mark for high-res timestamps on next update after getattr xfs: mark the inode for high-res timestamp update in getattr fs/inode.c | 57 +++++++++++++++++++++++++++--- fs/stat.c | 24 +++++++++++++ fs/xfs/libxfs/xfs_trans_inode.c | 2 +- fs/xfs/xfs_acl.c | 2 +- fs/xfs/xfs_inode.c | 2 +- fs/xfs/xfs_inode_item.c | 2 +- fs/xfs/xfs_iops.c | 9 +++-- fs/xfs/xfs_super.c | 5 ++- include/linux/fs.h | 62 +++++++++++++++++++++++---------- mm/shmem.c | 29 ++++++++------- 10 files changed, 152 insertions(+), 42 deletions(-) -- 2.40.0