From: "Arnd Bergmann" <arnd@arndb.de>
To: Jeff Layton <jlayton@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
David Sterba <dsterba@suse.cz>,
Amir Goldstein <amir73il@gmail.com>,
Theodore Ts'o <tytso@mit.edu>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>, Jeremy Kerr <jk@ozlabs.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>, Greg Kroah-Hartman <greg>
Cc: 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-d
Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers
Date: Thu, 28 Sep 2023 11:48:16 -0400 [thread overview]
Message-ID: <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> (raw)
In-Reply-To: <20230928110554.34758-2-jlayton@kernel.org>
On Thu, Sep 28, 2023, at 07:05, Jeff Layton wrote:
> This shaves 8 bytes off struct inode, according to pahole.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
FWIW, this is similar to the approach that Deepa suggested
back in 2016:
https://lore.kernel.org/lkml/1452144972-15802-3-git-send-email-deepa.kernel@gmail.com/
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.
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.
Arnd
next prev parent reply other threads:[~2023-09-28 15:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-28 11:05 [PATCH 85/87] fs: rename i_atime and i_mtime fields to __i_atime and __i_mtime Jeff Layton
2023-09-28 11:05 ` [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers Jeff Layton
2023-09-28 15:48 ` Arnd Bergmann [this message]
2023-09-28 17:06 ` Jeff Layton
2023-09-28 17:19 ` Darrick J. Wong
2023-09-28 17:40 ` Jeff Layton
2023-09-28 20:21 ` Arnd Bergmann
2023-09-28 21:26 ` Theodore Ts'o
2023-09-29 0:18 ` Linus Torvalds
2023-09-29 3:50 ` Amir Goldstein
[not found] ` <CAOQ4uxg5ctY9yCjLOjN1nETAcEuNb2UERnYuDv7PoErdxX=WUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-09-29 16:22 ` Linus Torvalds
2023-09-29 3:27 ` Amir Goldstein
[not found] ` <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2023-09-29 6:32 ` David Howells
2023-09-30 14:50 ` Steve French
2023-10-01 5:01 ` [OT] " Gabriel Paubert
2023-09-29 9:44 ` Christian Brauner
2023-09-29 10:16 ` Jeff Layton
2023-09-28 17:09 ` Jeff Layton
2023-09-28 11:05 ` [PATCH 87/87] fs: move i_blocks up a few places in struct inode Jeff Layton
2023-09-28 11:35 ` Amir Goldstein
2023-09-28 12:01 ` Jeff Layton
2023-09-28 17:41 ` Linus Torvalds
2023-09-28 18:01 ` Jeff Layton
2023-09-29 9:32 ` Christian Brauner
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=6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com \
--to=arnd@arndb.de \
--cc=agordeev@linux.ibm.com \
--cc=amir73il@gmail.com \
--cc=autofs@vger.kernel.org \
--cc=borntraeger@linux.ibm.com \
--cc=brauner@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=codalist@coda.cs.cmu.edu \
--cc=dsterba@suse.cz \
--cc=ebiederm@xmission.com \
--cc=gfs2@lists.linux.dev \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=jk@ozlabs.org \
--cc=jlayton@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-afs@lists.infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-nilfs@vger.kernel.org \
--cc=linux-ntfs-dev@lists.sourceforge.net \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=ntfs3@lists.linux.dev \
--cc=platform-driver-x86@vger.kernel.org \
--cc=svens@linux.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=v9fs@lists.linux.dev \
--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).