Re: [PATCH] fs: switch timespec64 fields in inode to discrete integers

[Jeff Layton <jlayton@kernel.org>]

On Sat, 2024-05-18 at 06:23 +0100, Matthew Wilcox wrote:
> On Fri, May 17, 2024 at 08:08:40PM -0400, Jeff Layton wrote:
> > For reference (according to pahole):
> > 
> >     Before:	/* size: 624, cachelines: 10, members: 53 */
> >     After: 	/* size: 616, cachelines: 10, members: 56 */
> 
> Smaller is always better, but for a meaningful improvement, we'd want
> to see more.  On my laptop running a Debian 6.6.15 kernel, I see:
> 
> inode_cache        11398  11475    640   25    4 : tunables    0    0    0 : slabdata    459    459      0
> 
> so there's 25 inodes per 4 pages.  Going down to 632 is still 25 per 4
> pages.  At 628 bytes, we get 26 per 4 pages.  Ar 604 bytes, we're at 27.
> And at 584 bytes, we get 28.
> 
> Of course, struct inode gets embedded in a lot of filesystem inodes.
> xfs_inode         142562 142720   1024   32    8 : tunables    0    0    0 : slabdata   4460   4460      0
> ext4_inode_cache      81     81   1184   27    8 : tunables    0    0    0 : slabdata      3      3      0
> sock_inode_cache    2123   2223    832   39    8 : tunables    0    0    0 : slabdata     57     57      0
> 
> So any of them might cross a magic boundary where we suddenly get more
> objects per slab.
> 
> Not trying to diss the work you've done here, just pointing out the
> limits for anyone who's trying to do something similar.  Or maybe
> inspire someone to do more reductions ;-)

Way to bust my bubble, Willy. ;-)

On a more serious note, I may be able to squeeze out another 4 bytes by
moving __i_ctime to a single 8 byte word. It's never settable from
userland, so we probably don't need the full range of times that a
timespec64 gives us there. Shrinking that may also make the multigrain
time rework simpler.

David Howells was also looking at removing the i_private field as well.
Since these structs are usually embedded in a larger structure, it's
not clear that we need that field. If we can make that work, it'll mean
another 8 bytes goes away on 64-bit arches.

IOW, I think there may be some other opportunities for shrinkage in the
future.
-- 
Jeff Layton <jlayton@kernel.org>