Re: [PATCH 03/22] xfs: add helpers to collect and sift btree block pointers during repair

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

On Thu, May 17, 2018 at 10:41:19AM +1000, Dave Chinner wrote:
> On Wed, May 16, 2018 at 03:05:37PM -0700, Darrick J. Wong wrote:
> > On Thu, May 17, 2018 at 07:32:37AM +1000, Dave Chinner wrote:
> > > On Wed, May 16, 2018 at 11:01:27AM -0700, Darrick J. Wong wrote:
> > > > So far I haven't noticed /much/ heat from this routine even with
> > > > deliberately aged filesystems, but that's probably due to the slab
> > > > allocator eating way more time. :(
> > > 
> > > Perhaps it is worth looking at using named slab caches for some of
> > > these objects to take some heat off of the heap slabs?
> > 
> > Early versions of repair actually did that to try to avoid fragmenting
> > the power-of-2 slabs by using named slab caches, but slub emits udev
> > events whenever a named slab is created, and the resulting horrible
> 
> Really? That's so gross!
> 
> Anyway, WTF are udev events on internal kernel slab cache creation
> needed for?

No idea.  slab and slob don't do it, just slub.

> > cacophony of udev rule processing ate an entire CPU core and uncovered
> > deadlocks in the parts of the slab management code that manage
> > /sys/kernel/slab.  That code /really/ does not like you creating and
> > removing slabs concurrently.
> 
> I wasn't suggesting dynamically creating slab caches during a repair
> operation, just have one for the structure type created when we
> first initialise the XFS kernel module like we do for xfs_buf,
> xfs_inode, etc. 

I know, I was abusing slab caches so that I could just dump everything
at the end by deleting the slab. :P

--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