Re: [PATCH 87/87] fs: move i_blocks up a few places in struct inode

Jeff Layton <[email protected]> Thu, 28 Sep 2023 08:01:50 -0400
Newsgroups gmane.linux.kernel.bpf,gmane.linux.file-systems,gmane.linux.kernel,gmane.linux.kernel.mm,gmane.linux.ports.ppc64.devel,gmane.linux.drivers.platform.x86.devel,gmane.linux.drivers.rdma,gmane.linux.serial,gmane.linux.usb.general,gmane.linux.kernel.autofs,gmane.comp.file-systems.btrfs,gmane.comp.file-systems.ceph.devel,gmane.comp.file-systems.coda.general,gmane.linux.kernel.efi,gmane.comp.file-systems.ext4,gmane.linux.file-systems.f2fs,gmane.linux.uml.devel,gmane.linux.drivers.mtd,gmane.linux.nfs,gmane.comp.file-systems.nilfs.user,gmane.linux.file-systems.ntfs.devel,gmane.linux.hardware.karma.devel,gmane.linux.file-systems.union,gmane.comp.file-systems.reiserfs.general,gmane.linux.kernel.cifs,gmane.network.samba.internals,gmane.linux.network,gmane.comp.security.apparmor,gmane.linux.kernel.lsm
Message-ID <[email protected]> 
On Thu, 2023-09-28 at 14:35 +0300, Amir Goldstein wrote:
> On Thu, Sep 28, 2023 at 2:06 PM Jeff Layton <[email protected]> wrote:
> > 
> > The recent change to use discrete integers instead of struct timespec64
> > in struct inode shaved 8 bytes off of it, but it also moves the i_lock
> > into the previous cacheline, away from the fields that it protects.
> > 
> > Move i_blocks up above the i_lock, which moves the new 4 byte hole to
> > just after the timestamps, without changing the size of the structure.
> > 
> 
> Instead of creating an implicit hole, can you please move i_generation
> to fill the 4 bytes hole.
> 
> It makes sense in the same cache line with i_ino and I could
> use the vacant 4 bytes hole above i_fsnotify_mask to expand the
> mask to 64bit (the 32bit event mask space is running out).
> 
> Thanks,
> Amir.
> 

Sounds like a plan. Resulting struct inode size is the same (616 bytes
with my kdevops kconfig). BTW: all of these changes are in my "amtime"
branch if anyone wants to pull them down.
--
Jeff Layton <[email protected]>