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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1F67AE743D3 for ; Fri, 29 Sep 2023 00:36:47 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=Pt2knsyP; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4RxWcs38Xjz3cm8 for ; Fri, 29 Sep 2023 10:36:45 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=Pt2knsyP; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=jlayton@kernel.org; receiver=lists.ozlabs.org) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4RxLPQ4DxMz3cTd; Fri, 29 Sep 2023 03:41:14 +1000 (AEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B374B61D44; Thu, 28 Sep 2023 17:41:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D74F5C433C7; Thu, 28 Sep 2023 17:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695922871; bh=q4Y+iRhQNw28trXDtNOjgA21Uv+IbPAACk59LAWJmZQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Pt2knsyPVF5IN2LrEHFDhKXAMR+bUOcTlyAAG093ma8ffe9kH/u7HXG2g+Td0GQbU dj6xCSvBaMeN3dkuuuxcxsY6aAAFekfxMF19xWrooSEMrmsfY/FrKOmIr30Ef9iwhy 6QfDCUZqE6k5rEywc5Ze8K4/SAUL1W/1QDmSbwueKYxqX2aaIVxDcPqg/lhskw8rFh jOw/ARPQHq26NmwE3QZN+kwE0QI6+60XvzrrVfZo0ayZcNh/tBcZ410YuqL9+lmQQb qZZexkDUvIABncMcV2ChnF/ASLiH8NqVr7NTUG7D+At/G4u0PnSWIbaDK60vBHhtw8 vViGtl0HWhtVQ== Message-ID: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers From: Jeff Layton To: "Darrick J. Wong" Date: Thu, 28 Sep 2023 13:40:55 -0400 In-Reply-To: <20230928171943.GK11439@frogsfrogsfrogs> References: <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 29 Sep 2023 10:31:49 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Latchesar Ionkov , Konstantin Komarov , "Rafael J . Wysocki" , Hugh Dickins , Anders Larsen , Carlos Llamas , Andrii Nakryiko , Mattia Dongili , John Johansen , Yonghong Song , Alexander Gordeev , Christoph Hellwig , Mike Marshall , Paulo Alcantara , linux-xfs@vger.kernel.org, James Morris , Christoph Hellwig , Christian Borntraeger , devel@lists.orangefs.org, Shyam Prasad N , linux-um@lists.infradead.org, Nicholas Piggin , Alexander Viro , Eric Van Hensbergen , Suren Baghdasaryan , Trond Myklebust , Anton Altaparmakov , Christian Brauner , Greg Kroah-Hartman , Stephen Smalley , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Ronnie Sahlberg , Sergey Senozhatsky , Arve =?ISO-8859-1?Q?Hj=F8nnev=E5g?= , Chuck Lever , Sven Schnelle , Jiri Olsa , Jan Kara , Tejun Heo , Andrew Morton , linux-trace-kernel@vger.kernel.org, Linus Torvalds , Dave Kleikamp , linux-mm@kvack.org, Joel Fernandes , Eric Dumazet , Stanislav Fomichev , linux-s390@vger.kernel.org, linux-nilfs@vger.kernel.org, Paul Moore , Leon Romanovsky , John Fastabend , Luis Chamberlain , codalist@coda.cs.cmu.edu, Iurii Zaikin , Namjae Jeon , Masami Hiramatsu , Todd Kjos , Vasily Gorbik , selinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, reiserfs-devel@vger.kernel.org, Miklos Szeredi , Yue Hu , Jaegeuk Kim , Martijn Coenen , OGAWA Hirofumi , Hao Luo , Tony Luck , Theodore Ts'o , Nicolas Pitre , linux-ntfs-dev@lists.sourceforge.net, Muchun Song , linux-f2fs-devel@lists.sourceforge.net, "Guilherme G. Piccoli" , gfs2@lists.linux.dev, "Eric W. Biederman" , Anna Schumaker , Brad Warrum , Mike Kravetz , linux-efi@vger.kernel.org, Martin Brandenburg , ocfs2-devel@lists.linux.dev, Alexei Starovoitov , platform-driver-x86@vger.kernel.org, Chris Mason , linux-mtd@lists.infradead.org, linux-hardening@vger.kernel.org, Marc Dionne , Jiri Slaby , linux-afs@lists.infradead.org, Ian Kent , Naohiro Aota , Daniel Borkmann , Dennis Dalessandro , linux-rdma@vger.kernel.org, coda@cs.cmu.edu, Ilpo =?ISO-8859-1?Q?J=E4rvinen?= , Ilya Dryomov , Paolo Abeni , "Serge E. Hallyn" , Christian Schoenebeck , Kees Cook , Arnd Bergmann , autofs@vger.kernel.org, Steven Rostedt , Mark Gross , Damien Le Moal , Eric Paris , ceph-devel@vger.kernel.org, Gao Xiang , Jan Harkes , linux-nfs@vger.kernel.org, linux-ext4@vger.kernel.org, Olga Kornievskaia , Song Liu , samba-technical@lists.samba.org, Steve French , Jeremy Kerr , Netdev , Bob Peterson , linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org, ntfs3@lists.linux.dev, linux-erofs@lists.ozlabs.org, "David S . Miller" , Chandan Babu R , jfs-discussion@lists.sourceforge.net, Jan Kara , Neil Brown , Dominique Martinet , Amir Goldstein , Bob Copeland , KP Singh , linux-unionfs@vger.kernel.org, David Howells , Joseph Qi , Andreas Dilger , Mikulas Patocka , Ard Biesheuvel , Anton Ivanov , Andreas Gruenbacher , Richard Weinberger , Mark Fasheh , Dai Ngo , Jason Gunthorpe , linux-serial@vger.kernel.org, Jakub Kicinski , Salah Triki , Evgeniy Dushistov , linux-cifs@vger.kernel.org, Heiko Carstens , Chao Yu , apparmor@lists.ubuntu.com, Josef Bacik , Tom Talpey , Hans de Goede , "Tigran A. Aivazian" , Dav id Sterba , Xiubo Li , Ryusuke Konishi , Johannes Thumshirn , Ritu Agarwal , Luis de Bethencourt , Martin KaFai Lau , v9fs@lists.linux.dev, David Sterba , linux-security-module@vger.kernel.org, Jeffle Xu , Phillip Lougher , Johannes Berg , Sungjong Seo , David Woodhouse , linux-karma-devel@lists.sourceforge.net, linux-btrfs@vger.kernel.org, Joel Becker Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, 2023-09-28 at 10:19 -0700, Darrick J. Wong wrote: > On Thu, Sep 28, 2023 at 01:06:03PM -0400, Jeff Layton wrote: > > On Thu, 2023-09-28 at 11:48 -0400, Arnd Bergmann wrote: > > > On Thu, Sep 28, 2023, at 07:05, Jeff Layton wrote: > > > > This shaves 8 bytes off struct inode, according to pahole. > > > >=20 > > > > Signed-off-by: Jeff Layton > > >=20 > > > FWIW, this is similar to the approach that Deepa suggested > > > back in 2016: > > >=20 > > > https://lore.kernel.org/lkml/1452144972-15802-3-git-send-email-deepa.= kernel@gmail.com/ > > >=20 > > > It was NaKed at the time because of the added complexity, > > > though it would have been much easier to do it then, > > > as we had to touch all the timespec references anyway. > > >=20 > > > The approach still seems ok to me, but I'm not sure it's worth > > > doing it now if we didn't do it then. > > >=20 > >=20 > > I remember seeing those patches go by. I don't remember that change > > being NaK'ed, but I wasn't paying close attention at the time=20 > >=20 > > Looking at it objectively now, I think it's worth it to recover 8 bytes > > per inode and open a 4 byte hole that Amir can use to grow the > > i_fsnotify_mask. We might even able to shave off another 12 bytes > > eventually if we can move to a single 64-bit word per timestamp.=20 >=20 > I don't think you can, since btrfs timestamps utilize s64 seconds > counting in both directions from the Unix epoch. They also support ns > resolution: >=20 > struct btrfs_timespec { > __le64 sec; > __le32 nsec; > } __attribute__ ((__packed__)); >=20 Correct. We'd lose some fidelity in currently stored timestamps, but as Linus and Ted pointed out, anything below ~100ns granularity is effectively just noise, as that's the floor overhead for calling into the kernel. It's hard to argue that any application needs that sort of timestamp resolution, at least with contemporary hardware.=20 Doing that would mean that tests that store specific values in the atime/mtime and expect to be able to fetch exactly that value back would break though, so we'd have to be OK with that if we want to try it. The good news is that it's relatively easy to experiment with new ways to store timestamps with these wrappers in place. --=20 Jeff Layton