Re: [PATCH RFC DRAFT DOESNOTBUILD] inode: free up more space

Christian Brauner
2025-07-16T12:53:25Z

On Tue, Jul 15, 2025 at 05:09:03PM +0100, Matthew Wilcox wrote:
> On Tue, Jul 15, 2025 at 04:35:24PM +0200, Christian Brauner wrote:
> > struct inode is bloated as everyone is aware and we should try and
> > shrink it as that's potentially a lot of memory savings. I've already
> > freed up around 8 bytes but we can probably do better.
>
> OK, but let's make sure we're actually achieving memory savings.
> First, inodes are allocated from slabs. If we reduce a struct from,
> say, 596 to 592 bytes, we'll still get 27 of them in a 16KiB page
> (although we'd get 110 instead of 109 in a 64KiB page!) so we need
> to be crossing some important boundaries to actually make a difference.
>
> For block/network filesystems, those slabs are fs-private with
> struct inode embedded into struct fs_inode. eg:
>
> xfs_inode 584600 593856 1024 32 8 : tunables 0 0 0 : slabdata 18558 18558 0
> ext4_inode_cache 756 756 1168 28 8 : tunables 0 0 0 : slabdata 27 27 0
> proc_inode_cache 18316 19136 704 46 8 : tunables 0 0 0 : slabdata 416 416 0
> inode_cache 8059 9325 632 25 4 : tunables 0 0 0 : slabdata 373 373 0
>
> That's on a machine running 6.12 and pahole tells me struct inode is
> currently 624 bytes, so yes, you've saved 8 bytes (Debian config).
> And we've gone from 25 objects per 16KiB to 26, so yay! Getting to 27
> will be harder, we have to get to 604 bytes. Although for my system if
> we could get xfs_inode down from 1024 bytes to 992, that'd save me much
> more memory ;-)
>
> We could get rid of i_io_list by using an allocating xarray to store the
> inodes in each backing_dev. There's 16 bytes (would probably need to
> retain a 4 byte ID to allow for efficient deletion from the xarray,
> and there are multiple lists it might be on, so perhaps 3 bits to
> determine which list it's on).
>
> That might work for i_sb_list, i_sb_list and i_lru too. That could get
> us 48 bytes.
>
> We can also win in inode by shrinking address_space. nr_thps is
> one I want to kill. That'll get us 8 bytes back as soon as btrfs
> lets us drop CONFIG_READ_ONLY_THP_FOR_FS.
>
> The i_private_* members in i_data can probably also go. Mostly they're
> used for buffer_heads. So more conversion to iomap will help with that.
>
>
> I wonder if we can shift from having i_data embedded in struct inode
> to embedding it in struct foofs_inode. Then procfs and other pseudo
> filesystems wouldn't allocate 192 bytes worth of data ...

If you/or someone manages to do that work before LSFMM in May 2026 I'll
bring the author a VFS T-Shirt with "I shrunk struct inode by $n bytes."
LSFMM 2026 edition.