On Tue, Jan 12, 2016 at 07:30:10AM -0800, Christoph Hellwig wrote: > Nice! > > I had started on some of this a while ago but never finished it.. *nod* > > 72 bytes. This means it takes 104 bytes off the size of the struct > > xfs_inode, which a 12% reduction in size. This will be a massive win > > for systems that cache lots of inodes! > > How many more inodes can we fit into a slab cache now? Back when I > started I noticed it doesn't help us to actually fit more inodes into > a 4k page due to the bloated VFS inode. But these days slub actually > uses a high order allocations if I remember correctly so it might be > more useful. On a debug build (because that's the only numbers I have at hand), the current code is 1280 bytes/inode, 25 inodes/slab, 8 pages/slab. This patch set makes it 1152 bytes/inode, 28 inodes/slab, 8 pages/slab, so that's a 12% increase in the number of cached inodes for a given amount of slab memory. IIRC, a production build is around 960 bytes/inode, so that would put it at 34 inodes/slab for the current code and 38 inodes/slab for the current patchset. That, again, is roughly 12% increase in inodes per slab.... > > With this change made, the xfs_icdinode is no long an "in core disk > > inode" so I'm wondering whether I should rename it or simply make it > > go away altogether and pull the remaining fields straight into the > > struct xfs_inode. Any thoughts on new names and/or getting rid of it > > woul dbe appreciated. > > I think it should be merged into the xfs_inode structure soner or > later. Ok, I'll look at doing that. > Another thign I planned but never got to is to move fields > into the inode fork that were specific to the attr or data fork. That's a whole different problem ;) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
