Messages in this thread | | | From | Neil Brown <> | Date | Fri, 21 Jul 2000 12:34:38 +1000 (EST) | Subject | Re: [patch-2.4.0-test5-pre3] struct inode shortened |
| |
On Thursday July 20, manfred@colorfullife.com wrote: > On Thu, 20 Jul 2000, Linus Torvalds wrote: > > > I wasn't serious. > > > > It was a comment to your "if you have a million inodes it's a lot of bits" > > comment. > > > > Considering that the inode is probably 200+ bytes, the million inodes case > > is fairly scary. And the 4 bytes won't be that noticeable.. > > > > around 416 bytes [just cat /proc/slabinfo, the third number is size, > rounded to cache line size] > > > You'd save more by making the quota stuff go away when quotas aren't > > enabled.. > > > > Or by removing a superflous variable in each buffer head: the kiobuf code > adds it's own callback parameter instead of using the generic one.
Ok, I'll bite...
Only one of i_rdev and i_size are needed at a time, so we could union them.
i_zombie is only needed on diretories. i_flock is (I suspect) not needed on directories, so we can union them. They can be in the same union as i_pipe and i_bdev I suspect (hmmm. can you lock range of a block device?)
i_blksize is constant across filesystems, so it can be moved to the superblock (I suspect that I am actualy wrong here. There is probably a good reason for it to be in the inode, but I cannot pick it).
i_state is a long, and has 4 bits defined! We should make it a char and put it next to i_sock. Would save 7 bytes on an alpha.
Of the 356 bytes in struct inode (on i386) 132 are in the union at the end. The largest few components of these are: nfs_i 132 ext2_i 116 efs_i 104 affs_i 104 ufs_i 100
For people not using client-nfs, being able to compile witout it would save 16 bytes per inode, 4%.
Turning our attention to ext2, as ext2 doesn't actually do fragmentation of blocks, i_frag_no and i_frag_size could be removed saving 2 bytes. not_used_1 could be removed (PLEASE!!) saving 4 bytes.
All up, I suspect we could trim 10% off the inode size which might almost be considered to be significant????
NeilBrown
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |