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

[Matthew Wilcox <willy@infradead.org>]

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 ...