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

Matthew Wilcox
2025-07-15T16:09:12Z

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