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