Re: [DISCUSSION] Revisiting Slab Movable Objects

[Harry Yoo <harry.yoo@oracle.com>]

On Wed, Apr 23, 2025 at 02:47:32AM +0100, Al Viro wrote:
> On Tue, Apr 22, 2025 at 07:54:08AM +1000, Dave Chinner wrote:
> 
> > I don't have a solution for the dentry cache reference issues - the
> > dentry cache maintains the working set of files, so anything that
> > randomly shoots down unused dentries for compaction is likely to
> > have negative performance implications for dentry cache intensive
> > workloads.
> 
> Just to restate the obvious: _relocation_ of dentries is hopeless for
> many, many reasons - starting with "hash of dentry depends upon
> the address of its parent dentry".

If we can't migrate or reclaim dentries with a nonzero refcount,
can we at least prevent slab pages from containing a mix of dentries
with zero and nonzero refcounts?

An idea: "Migrate a dentry (and inode?) _before_ it becomes unrelocatable"
This is somewhat similar to "Migrate a page out of the movable area before
pinning it" in MM.

For example, suppose we have two slab caches for dentry:
dentry_cache_unref and dentry_cache_ref.

When a dentry with a zero refcount is about to have its refcount
incremented, the VFS allocates a new object from dentry_cache_ref, copies
the dentry into it, frees the original dentry back to
dentry_cache_unref, and returns the newly allocated object.

Similarly when a dentry with a nonzero refcount drops to zero,
it is migrated to dentry_cache_unref. This should be handled on the VFS
side rather than by the slab allocator.

This approach could, at least, help reduce fragmentation.

> Freeing anything with zero refcount...
> sure, no problem - assuming that you are holding rcu_read_lock(),
> 	if (READ_ONCE(dentry->d_count) == 0) {
> 		spin_lock(&dentry->d_lock);
> 		if (dentry->d_count == 0)
> 			to_shrink_list(dentry, list);
> 		spin_unlock(&dentry->d_lock);
> 	}
> followed by rcu_read_unlock() and shrink_dentry_list(&list) once you
> are done collecting the candidates.  If you want to wait for them to
> actually freed, synchronize_rcu() after rcu_read_unlock() (freeing is
> RCU-delayed).
> 
> Performance implications are separate story - it really depends upon
> a lot of details.  But simple "I want all unused dentries in this
> page kicked out" is doable.  And in-use dentries are no-go, no matter
> what.

Thank you for the detailed guidance and confirming that it's doable!
It will be very helpful when implementing this.

-- 
Cheers,
Harry / Hyeonggon