On Thu, Jan 04, 2024 at 08:17:35AM +0100, Christoph Hellwig wrote: > On Wed, Jan 03, 2024 at 11:14:54PM -0800, Darrick J. Wong wrote: > > IIRC setting up the shrinker in xfs_alloc_buftarg_common takes some > > shrinker lock somewhere, and lockdep complained about a potential > > deadlock between the locks that scrub takes if I don't create the xfile > > buftarg in the scrub _setup routines. That's why it's not created > > internally to the xfbtree. > > > > I agree that it makes much more sense only to create those things when > > they're actually needed, but ... hm. Maybe we don't need the xfile > > buftarg to be hooked up to the shrinkers, seeing as it's ephemeral > > anyway? That would save a lot of fuss and ... > > Yes, once we move to a model where the buffer always points to > the shmem page, and we remove the buffer lru for them as we already > have the page LRU there is no point in having a shrinker at all. Ok. I'll move the shrinker stuff into the real buftarg creation function. This seems to have become a lot simpler now that the shrinker is a pointer instead of embedded in the buftarg. > > > naming and moving it out of scrub/ would make sense as the concept > > > isn't really scrub/repair specific. But if we want to stick with > > > it I'd prefer to not also have _mem-based naming. > > > > Yes, lets move it to libxfs/xfbtree.[ch]. > > What does the xf in the various scrubx/xf* thinks stand for, btw? > Why not libxfs/xfs_btree_mem.[ch]? "xfile btree". --D
