Code now merged for the Linux 7.1 kernel may provide some negative performance implications for those still running modern Linux kernels on 32-bit hardware. A fundamental change can present cache line alignment and slab sizing implications for 32-bit Linux OS users but will provide for cleaner code with modern 64-bit computing.
The Linux kermnel’s inode “i_ino” field is an unsigned long that over the years has led file-systems to implement “hacks” for hashing 64-bit identifiers into a 32-bit field. For Linux 7.1 that field is being changed to u64 for being able to avoid such messy hacks moving forward. But this comes at the cost of a larger struct inode for 32-bit users that may cause some side effects around cache line alignment and slab sizing.
The pull request, which was already merged by Linus Torvalds, explains of this Linux 7.1 VFS change:
“For historical reasons, the inode->i_ino field is an unsigned long, which means that it’s 32 bits on 32 bit architectures. This has caused a number of filesystems to implement hacks to hash a 64-bit identifier into a 32-bit field, and deprives us of a universal identifier field for an inode.
The work in this pr changes the inode->i_ino field from an unsigned long to a u64. This shouldn’t make any material difference on 64-bit hosts, but 32-bit hosts will see struct inode grow by at least 4 bytes. This could have effects on slabcache sizes and field alignment.
The bulk of the changes are to format strings and tracepoints, since the kernel itself doesn’t care that much about the i_ino field. The first patch changes some vfs function arguments, so check that one out carefully.
With this change, we may be able to shrink some inode structures. For instance, struct nfs_inode has a fileid field that holds the 64-bit inode number. With this set of changes, that field could be eliminated. I’d rather leave that sort of cleanups for later just to keep this simple.”
Jeff Layton who pursued this change had commented back in February when bringing up the topic of changing the field size:
“I think that the biggest problem will be that this will grow struct inode on 32-bit arches by at least 4 bytes. That may have cacheline alignment and slab sizing implications. We’re actively talking about deprecating 32-bit arches in the future however, so maybe we can rationalize that away.”
The patches that address this change were also generated in part by a large language model (LLM), Claude in particular. Layton later clarified on the LLM usage:
“Much of this set was generated by LLM, but I attributed it to myself since I consider this to be in the “menial tasks” category of LLM usage.”
This widening of the “ino” fields is ultimately a win for the modern 64-bit world but with potential implications for those still running modern Linux kernels on a 32-bit OS.
