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