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