Received: by 2002:a05:7412:2a8c:b0:e2:908c:2ebd with SMTP id u12csp3413489rdh; Thu, 28 Sep 2023 10:49:39 -0700 (PDT) X-Google-Smtp-Source: AGHT+IENSAARWRwHjy76T5pKpy4ckHfuzgHqHn0kFhPbsPOQvoodlLM+3trjOGFxwmQ8FL0rAvJk X-Received: by 2002:a17:90a:ab91:b0:279:11db:2fe1 with SMTP id n17-20020a17090aab9100b0027911db2fe1mr1847336pjq.31.1695923378946; Thu, 28 Sep 2023 10:49:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695923378; cv=none; d=google.com; s=arc-20160816; b=a9qrzyo5WGs30MtnVl07X9dfwa01K0tOdZ8hvK+rRzAuNKU2S1XdWz3By3p2Ew0XCf H5I31mLywXxPkdvlYR9uTTlsxF3ek5UVbMLvqOGIQniQemZJs066Ml9Bknnd3mMS8jsM WV8EtyvD77kBoW50V3Q184g4dkec+rwMSUZiYy6pyLzqV/TYkDtNCFbg9SUJ4Czrk+RA 5WaP8sD6YqDCVIYKy/FHQYzqY9TTNf6IC8oWxznk4h786lZiZKS27L/R10CH177BTRe3 j9Hr8dGmQurcy4eM1WsCcQxRYDFCUTAuqD4aWppqfiN3JwzctSG4pt2RCOhxgwlkRqI6 3lRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=rVggu1VGkpV0qV9Uxlve5gkwdkEZMgxtHMU8GWm+HHo=; fh=tZu+x8/SfrPLOt3Nz2c8C86DqurfYVrVsy3j0Bqc0s8=; b=T7FuTRYS99ejKxW4ulp5z/pALj98wziYS1UrY0Lmsy3dygMNw23HiXt/cSsAb8/y5U UAzCr5qomsmFuFdI0N49bmYv/MNFg5vFgzk4DfeN5XbbTuhisTrWBNDP8N6sd8u6Myjs bkkviYdWHpqFUTEc39hPvWZnhNcWsJD2kSrtmPuyn3wStjTIZfVmdR64pMMqDnKiZmtd PybmLuWRTbdV3wizfzbotNZYgsQVGvIqWZ3w+RvmTYWCB5ZFSyJGMBp9RFH9gqYLMtaV omhR9i8G8vFnTQ0uOvMS5QGmCycwWUY3oyrV6aLVzNxdCx6B1cI7h1pEbREsnBFB+/Uc WvIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Pt2knsyP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id g7-20020a17090a300700b00278f2f6b412si6219314pjb.164.2023.09.28.10.49.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Sep 2023 10:49:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Pt2knsyP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 93B898023091; Thu, 28 Sep 2023 10:41:41 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232039AbjI1RlS (ORCPT + 99 others); Thu, 28 Sep 2023 13:41:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229478AbjI1RlO (ORCPT ); Thu, 28 Sep 2023 13:41:14 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6D1719E; Thu, 28 Sep 2023 10:41:11 -0700 (PDT) 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" Cc: Arnd Bergmann , Alexander Viro , Christian Brauner , Linus Torvalds , David Sterba , Amir Goldstein , Theodore Ts'o , "Eric W. Biederman" , Kees Cook , Jeremy Kerr , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Greg Kroah-Hartman , Arve =?ISO-8859-1?Q?Hj=F8nnev=E5g?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Carlos Llamas , Suren Baghdasaryan , Mattia Dongili , Dennis Dalessandro , Jason Gunthorpe , Leon Romanovsky , Brad Warrum , Ritu Agarwal , Hans de Goede , Ilpo =?ISO-8859-1?Q?J=E4rvinen?= , Mark Gross , Jiri Slaby , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , David Sterba , David Howells , Marc Dionne , Ian Kent , Luis de Bethencourt , Salah Triki , "Tigran A. Aivazian" , Chris Mason , Josef Bacik , Xiubo Li , Ilya Dryomov , Jan Harkes , coda@cs.cmu.edu, Joel Becker , Christoph Hellwig , Nicolas Pitre , "Rafael J . Wysocki" , Ard Biesheuvel , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Namjae Jeon , Sungjong Seo , Jan Kara , Andreas Dilger , Jaegeuk Kim , OGAWA Hirofumi , Christoph Hellwig , Miklos Szeredi , Bob Peterson , Andreas Gruenbacher , Richard Weinberger , Anton Ivanov , Johannes Berg , Mikulas Patocka , Mike Kravetz , Muchun Song , Jan Kara , David Woodhouse , Dave Kleikamp , Tejun Heo , Trond Myklebust , Anna Schumaker , Chuck Lever , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey , Ryusuke Konishi , Anton Altaparmakov , Konstantin Komarov , Mark Fasheh , Joseph Qi , Bob Copeland , Mike Marshall , Martin Brandenburg , Luis Chamberlain , Iurii Zaikin , Tony Luck , "Guilherme G. Piccoli" , Anders Larsen , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Sergey Senozhatsky , Phillip Lougher , Steven Rostedt , Masami Hiramatsu , Evgeniy Dushistov , Chandan Babu R , Damien Le Moal , Naohiro Aota , Johannes Thumshirn , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Hugh Dickins , Andrew Morton , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Johansen , Paul Moore , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-rdma@vger.kernel.org, linux-serial@vger.kernel.org, linux-usb@vger.kernel.org, v9fs@lists.linux.dev, linux-afs@lists.infradead.org, autofs@vger.kernel.org, linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org, codalist@coda.cs.cmu.edu, linux-efi@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, gfs2@lists.linux.dev, linux-um@lists.infradead.org, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, linux-nfs@vger.kernel.org, linux-nilfs@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, ntfs3@lists.linux.dev, ocfs2-devel@lists.linux.dev, linux-karma-devel@lists.sourceforge.net, devel@lists.orangefs.org, linux-unionfs@vger.kernel.org, linux-hardening@vger.kernel.org, reiserfs-devel@vger.kernel.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-trace-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, bpf@vger.kernel.org, Netdev , apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, selinux@vger.kernel.org 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-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Thu, 28 Sep 2023 10:41:41 -0700 (PDT) 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