From patchwork Wed Oct 18 17:41:07 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 13427575 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 B66B7CDB482 for ; Wed, 18 Oct 2023 17:41:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3DD3C8D0176; Wed, 18 Oct 2023 13:41:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 38D698D0016; Wed, 18 Oct 2023 13:41:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22DFC8D0176; Wed, 18 Oct 2023 13:41:35 -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 125CB8D0016 for ; Wed, 18 Oct 2023 13:41:35 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id DE95C160414 for ; Wed, 18 Oct 2023 17:41:34 +0000 (UTC) X-FDA: 81359299308.08.AB8939E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id 1824912001E for ; Wed, 18 Oct 2023 17:41:32 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HmbULKUS; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf29.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697650893; 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-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=g6RLbkas4syt5zlxH2JHkSI99xiQPowP3ECM9V8lGGk=; b=l3OA0gra9LCKSOHkPWusLu0O9RQdRMhusLpjR8mAHGaVgR6YmmFub74vnRo1jTQeeSL02o 35Pt2Asjk6ZL7jrR6OBINTZfne5jH16iOX6/uGdYg5jd1NeebVS/OswCcLg/rUqEb9nr/5 OEs7mFYrBT59J9ipXfxPb+FwgTTm2UM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HmbULKUS; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf29.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697650893; a=rsa-sha256; cv=none; b=SwZbSyd4ax7WByxykEs79Ms78A/PcCcURnaIWysUaSGoAob0mCIAc5UcaSxi3n/stKRKMw wGawISkKwDepVEq9hK4XUdL4hW7rmqcYBCTt3sIf/yDwsDOuq+t9NpN+q8erS8a1W0HHoM onj+MKoXCctfr+zEOBJ3Mg5DU1DqwQE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1344D61888; Wed, 18 Oct 2023 17:41:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76D2FC433C8; Wed, 18 Oct 2023 17:41:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697650891; bh=kOWxubIvgkUuX1LHF9Uvd3PXOcCevsiFIHXsUMPyfII=; h=From:Subject:Date:To:Cc:From; b=HmbULKUSdAVTYh0NKXFEKevWhFCUwYFMuL4ZE6MnHrMRc//1huWLlflMoK0S8D7HT RpsmiCca/5mXfeyTb19e8+kl8UJFzEghrdotH3KvXYHZLUsXcKKlbUVfvdQyMx62z6 34Xsrh7WT/00XDtz5t6InI84zeLOx7tPeu8rJA9Rwn1Zx9HeCyi0I3fC4LOiYur/fE JDN4Vyc3XcT+ERm/aUw1zN6TI4Le3vB5HM60CU8WN2sV4b/rcSCzdsY2aZvIqYa99Z sjX65S2Oku9xYqAVYGzUC0sAqceFqJ82GaotgiDmurcJyHeCgtRQvu9Ale3NAijBbP rOv1uoNIL4Tnw== From: Jeff Layton Subject: [PATCH RFC 0/9] fs: multigrain timestamps (redux) Date: Wed, 18 Oct 2023 13:41:07 -0400 Message-Id: <20231018-mgtime-v1-0-4a7a97b1f482@kernel.org> MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIALMYMGUC/6tWKk4tykwtVrJSqFYqSi3LLM7MzwNyDHUUlJIzE vPSU3UzU4B8JSMDI2NDA0Mz3dz0kszcVN20VOPURHPTZLM0U0sloOKCotS0zAqwQdFKQW7OSrG 1tQAHBm97XQAAAA== To: Linus Torvalds , Alexander Viro , Christian Brauner , John Stultz , Thomas Gleixner , Stephen Boyd , Chandan Babu R , "Darrick J. Wong" , Dave Chinner , Theodore Ts'o , Andreas Dilger , Chris Mason , Josef Bacik , David Sterba , Hugh Dickins , Andrew Morton , Amir Goldstein , Jan Kara , David Howells Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org, Jeff Layton X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=5629; i=jlayton@kernel.org; h=from:subject:message-id; bh=kOWxubIvgkUuX1LHF9Uvd3PXOcCevsiFIHXsUMPyfII=; b=owEBbQKS/ZANAwAIAQAOaEEZVoIVAcsmYgBlMBjAuucpyDoopVPNBPSV5kIUK51y3+JkIuJbJ MfA0arDDZaJAjMEAAEIAB0WIQRLwNeyRHGyoYTq9dMADmhBGVaCFQUCZTAYwAAKCRAADmhBGVaC FRcGD/4gWTfDUlUYR99pZVwm1+RHd3+PX9zlbEqYbvDvs6/aA8B9q7koy4wlyncLKHzM5nrgYHf rFzENOpzsSadkGkDajVLKfFaQ7akLUv8uZiji9WsSoT+e1AyWZj0DskG0JKmYteynPzh30YyJL0 KHzsJ7pfrumiZBtdXtMJAa8Skoueq0gWV/7oshhybg6JEOMLOQ+4ANJDMsIfpb6+sHdFitMACRF q4gKZPjsX7FZIx1dd0SQdMlRjw4An+JYEwgjP3bkdy7XTjz6sW5sitQstxEDS/JaxZ6XIIL7xqB OO/Jkxmo5/vSa05/4RVeplhTkAh1uV5n4LuWsjuh+Q8bON7Zv4VKdYJP8r9WBL/5zQwCPpHM2SO c5eE9cT+BmXGcJIzAw52UsXAbp0LO+gYHlR+G7q+I5GEVg2+g6LFRoxL0+OpYvIWcycfYQps5NH XnbuDRwrAVg96y3GpdKaOGuEzu1Sm5CLNXS0jYorIwAossaz50WdaaVRJxMjPRinrp+sP8fv7+l h2X/0Yla61mKX6fZZArxV7sA9uEGbMcZPQcXRw5DW7EhjKh1QbyGwF46sawjrX93/UoxFvWEHso iVcm5rVdVOTBwEy9iFhY241oVCW3E7NtCZ/SNf/hiaRQFTl/Sn7Q3aluI/ogOfLPa0eG+eRYdo8 H373khRmD98lzxQ== X-Developer-Key: i=jlayton@kernel.org; a=openpgp; fpr=4BC0D7B24471B2A184EAF5D3000E684119568215 X-Rspamd-Queue-Id: 1824912001E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: fxxudtx77eqq6swi3cuzcztz1wx3qyq5 X-HE-Tag: 1697650892-487550 X-HE-Meta: U2FsdGVkX19fYRkztoV460SSDXpCZkcVxIyhlhlKbrmljD4nn1O6Gwu9ehgQEjb5EDN4huT+GvE4Hmqrya87AtCrMgWt2GR97w4Nt7HqZ2YEmbFQgjKszzxJInVCD1KQIn1VokXVlorK44VWF+UHtH4BUB/yAb1wOi0avc0IC+Hqgcsng6mfCbBRfV+x/IY3BMYD2dAaCefWCvcYpJ8BXvPv97jW3RQqHq5FCoKf8In+FLZebncO1jR7qRu+MyVOf6d/PkoXWmNLX/afyBMW0riAc5Lu375xF6opIn5rNd7Bw9h54N3mDnDQo1O5j0MlRRcHMssVivnShUfF32pRp/xLHv5hcPruqVOQzWn/lUowe+vydSJ0mdKgeDMtxq5DhlpK+3O6+bZqbZ6GFJWm48sJtlZXp5fw50mO/OqJHaoKO9HWPRbIwzJlNTnggvxHELjLZlhRADjcxSKFupvPd0YXJYwSf+BlVVfHOYUKXLpjW/umww9UqjYjmVW1FG9xNuMY2nUVK7xENcwEz8QK+EibL4ODuSbzilw5C8zqs2W23VKzuwq2nCpSbXofZAupqx12akmLXtZlZnqkkVTO/syidBvXbEmECrVofGHtw6h5dpTyEyHkRO2E/8H+TZRHOs3lgvm1mXOpuWCBd7xGmmWcIiCXjKYD/DrCPcjlAM4MAcFDx7/H7KG7pJ83JsA9q0yy9+UE2CVFY19/XtFdJKluWFZ1tGpGiWqE3tfOUaEoPlW/M1CJNQZS0kzhRlxRqwcr1npk593T16SDEAooZqNQPBKUAFskAQC/bZTGeloL9DMT770HKXSBMQq2hDyhFqWrt3NLKtUO3gIdEQgBUagLOLfovRBC8pcumgylzhgeWEBJ/hpXOHw4qVG5tLsZY74fE4GRiXXOtXbCBZLatsZFHXv1XbFH0gOyE7XDKTjY3wOt2uqbBdBf2mWLUQLIb7GPBBbEP24KdUF2tpA L+tvwnRD nV7WKOBg6zcl+d3a453DMz7R6k3Fi/qtadTy3z9Hhqzi8TB6NUP2rgTPNVXZP1Ry0NimshNEuZijUYpPMmIYGoxLm8rexMmBE2MFFn/YKm/F39c5AL+yifjigRsbyrjmoK3B0jZPB85nMoYbgHcF64fmWDrIAbx+DS3UhkxjYGCjIRXMrRtCs0HdiuNDPEev5Gw3PPJ/WCUoLSAMBMKrLV6/k4Mn8XKjqjeYf1l+cJO6IWWAxGu58KJ6I6mlCCrid+kGc 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: The VFS always uses coarse-grained timestamps when updating the ctime and mtime after a change. This has the benefit of allowing filesystems to optimize away a lot metadata updates, down to around 1 per jiffy, even when a file is under heavy writes. Unfortunately, this coarseness has always been an issue when we're exporting via NFSv3, which relies on timestamps to validate caches. A lot of changes can happen in a jiffy, so timestamps aren't sufficient to help the client decide to invalidate the cache. Even with NFSv4, a lot of exported filesystems don't properly support a change attribute and are subject to the same problems with timestamp granularity. Other applications have similar issues with timestamps (e.g backup applications). If we were to always use fine-grained timestamps, that would improve the situation, but that becomes rather expensive, as the underlying filesystem would have to log a lot more metadata updates. What we need is a way to only use fine-grained timestamps when they are being actively queried. The idea is to use an unused bit in the ctime's tv_nsec field to mark when the mtime or ctime has been queried via getattr. Once that has been marked, the next m/ctime update will use a fine-grained timestamp. The original merge of multigrain timestamps for v6.6 had to be reverted, as a file with a coarse-grained timestamp could incorrectly appear to be modified before a file with a fine-grained timestamp, when that wasn't the case. This revision solves that problem by making it so that when a fine-grained timespec64 is handed out, that that value becomes the floor for further coarse-grained timespec64 fetches. This requires new timekeeper interfaces with a potential downside: when a file is stamped with a fine-grained timestamp, it has to (briefly) take the global timekeeper spinlock. Because of that, this set takes greater pains to avoid issuing new fine-grained timestamps when possible. A fine-grained timestamp is now only required if the current mtime or ctime have been fetched for a getattr, and the next coarse-grained tick has not happened yet. For any other case, a coarse-grained timestamp is fine, and that is done using the seqcount. In order to get some hard numbers about how often the lock would be taken, I've added a couple of percpu counters and a debugfs file for tracking both types of multigrain timekeeper fetches. With this, I did a kdevops fstests run on xfs (CRC mode). I ran "make fstests-baseline" and then immediately grabbed the counter values, and calcuated the percentage: $ time make fstests-baseline real 324m17.337s user 27m23.213s sys 2m40.313s fine 3059498 coarse 383848171 pct fine .79075661 Next I did a kdevops fstests run with NFS. One server serving 3 clients (v4.2, v4.0 and v3). Again, timed "make fstests-baseline" and then grabbed the multigrain counters from the NFS server: $ time make fstests-baseline real 181m57.585s user 16m8.266s sys 1m45.864s fine 8137657 coarse 44726007 pct fine 15.393668 We can't run as many tests on nfs as xfs, so the run is shorter. nfsd is a very getattr-heavy workload, and the clients aggressively coalesce writes, so this is probably something of a pessimal case for number of fine-grained timestamps over time. At this point I'm mainly wondering whether (briefly) taking the timekeeper spinlock in this codepath is unreasonable. It does very little work under it, so I'm hoping the impact would be unmeasurable for most workloads. Side Q: what's the best tool for measuring spinlock contention? It'd be interesting to see how often (and how long) we end up spinning on this lock under different workloads. Note that some of the patches in the series are virtually identical to the ones before. I stripped the prior Reviewed-by/Acked-by tags though since the underlying infrastructure has changed a bit. Comments and suggestions welcome. Signed-off-by: Jeff Layton --- Jeff Layton (9): fs: switch timespec64 fields in inode to discrete integers timekeeping: new interfaces for multigrain timestamp handing timekeeping: add new debugfs file to count multigrain timestamps fs: add infrastructure for multigrain timestamps fs: have setattr_copy handle multigrain timestamps appropriately xfs: switch to multigrain timestamps ext4: switch to multigrain timestamps btrfs: convert to multigrain timestamps tmpfs: add support for multigrain timestamps fs/attr.c | 52 ++++++++++++++-- fs/btrfs/file.c | 25 ++------ fs/btrfs/super.c | 5 +- fs/ext4/super.c | 2 +- fs/inode.c | 70 ++++++++++++++++++++- fs/stat.c | 41 ++++++++++++- fs/xfs/libxfs/xfs_trans_inode.c | 6 +- fs/xfs/xfs_iops.c | 10 +-- fs/xfs/xfs_super.c | 2 +- include/linux/fs.h | 85 ++++++++++++++++++-------- include/linux/timekeeper_internal.h | 2 + include/linux/timekeeping.h | 4 ++ kernel/time/timekeeping.c | 117 ++++++++++++++++++++++++++++++++++++ mm/shmem.c | 2 +- 14 files changed, 352 insertions(+), 71 deletions(-) --- base-commit: 12cd44023651666bd44baa36a5c999698890debb change-id: 20231016-mgtime-fe3ea75c6f59 Best regards,