Re: [PATCH 15/18] xfs: remove support for inlining data/extents into the inode fork

["Darrick J. Wong" <darrick.wong@oracle.com>]

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@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html