On Fri, Nov 03, 2017 at 08:43:21AM +1100, Dave Chinner wrote: > On Thu, Nov 02, 2017 at 12:26:34PM -0700, Darrick J. Wong wrote: > > On Thu, Nov 02, 2017 at 07:57:25PM +0100, Christoph Hellwig wrote: > > > On Tue, Oct 31, 2017 at 03:35:08PM -0700, Darrick J. Wong wrote: > > > > Do you see any secondary effects, such as increased slab fragmentation > > > > because of the extra kmem_allocs? In general I think this should be ok, > > > > I just worry slightly that whatever reason we had for having > > > > if_inline_data is still around and will blow up in weird ways if we get > > > > rid of it. > > > > > > Why would we get much slab fragmentation? The small slabs (16 or 32 > > > byte for those current users) have a huge turnover, so they generally > > > aren't a majr problem. > > > > I don't think they will be a serious problem either; this is just me > > wondering why we had if_inline_data in the first place (now that we're > > removing it). > > Think back to ~1993 when XFS was first being implemented. State of > the art was 100-150MHz CPUs, and so the cost of an allocation for > every inode with a single data extent used a substantial fraction of > the available CPU. And given that most files are a single extent, > this was a worthwhile optimisation to minimise CPU overhead of the > initial data read on a file. Heh, that's what I expected was the reason. Carry on, then. :) > Nowdays, memory allocation costs less in terms of instructions than > it did on Irix in 1993, and the CPUs are also a couple of orders of > magnitudes faster. IOWs, the optimisation won't make as much > difference to performance now as it did 20 years ago... > > It's the same reason we have the data fork in the inode, but the > attr fork is dynamically allocated - every inode has it's data fork > referenced, but attr fork references are comparitively rare and > generally not performance sensitive and so allocating the attr fork > was a good trade-off between CPU overhead for those that needed > attrs vs lower memory usage for the larger majority of users... <nod> --D > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
