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