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.
