On Mon, Jun 17, 2024 at 11:29:42AM +1000, Dave Chinner wrote: > > > + if (mp->m_sb.sb_blocksize > PAGE_SIZE) > > > + igeo->min_folio_order = mp->m_sb.sb_blocklog - PAGE_SHIFT; > > > + else > > > + igeo->min_folio_order = 0; > > > } > > > > The minimum folio order isn't really part of the inode (allocation) > > geometry, is it? > > I suggested it last time around instead of calculating the same > constant on every inode allocation. We're already storing in-memory > strunct xfs_inode allocation init values in this structure. e.g. in > xfs_inode_alloc() we see things like this: While new_diflags2 isn't exactly inode geometry, it at least is part of the inode allocation. Folio min order for file data has nothing to do with this at all. > The only other place we might store it is the struct xfs_mount, but > given all the inode allocation constants are already in the embedded > mp->m_ino_geo structure, it just seems like a much better idea to > put it will all the other inode allocation constants than dump it > randomly into the struct xfs_mount.... Well, it is very closely elated to say the m_blockmask field in struct xfs_mount. The again modern CPUs tend to get a you simple subtraction for free in most pipelines doing other things, so I'm not really sure it's worth caching for use in inode allocation to start with, but I don't care strongly about that.
