Re: [viro-vfs:work.dcache2] [__dentry_kill()] 1b738f196e: stress-ng.sysinfo.ops_per_sec -27.2% regression

[Al Viro <viro@zeniv.linux.org.uk>]

On Mon, Dec 04, 2023 at 09:37:45PM +0800, Oliver Sang wrote:

> > OK, a carved-up series (on top of 1b738f196e^) is in #carved-up-__dentry_kill
> > That's 9 commits, leading to something close to 1b738f196e+patch you've tested
> > yesterday; could you profile them on your reproducers?  That might give some
> > useful information about the nature of the regression...
> >
> 
> we rerun the test and confirmed the regression still exists if comparing
> 20f7d1936e8a2 (viro-vfs/carved-up-__dentry_kill) step 9: fold decrment of parent's refcount into __dentry_kill()
> with
> b4cc0734d2574 d_prune_aliases(): use a shrink list
> 
> the data is similar to our previous report.
> 
> now we feed the results into our auto-bisect tool and hope to get results later

Thank you.
 
> but due to the limitation such like auto-bisect cannot capture multi commits if
> they all contribute to the regression, after we get the results from auto
> bisect, we will check if any further munual efforts needed. Thanks

My apologies for the number of steps in that ;-/

FWIW, what I'm really afraid of is this regression coming from #4; it might mean
that on some loads shrink_dcache_parent() benefits from evicting a parent while
it still has children halfway through ->d_iput().

That should not happen to sillyrenamed children, which is the only case where
the mainline instances of ->d_iput() currently access the parent, but that
depends upon too many subtle details spread over too many places ;-/

Oh, well - let's see what profiles show...  I still hope that it's not where
the trouble comes from - it would've lead the extra cycles in shrink_dcache_parent()
or d_walk() called from it and profiles you've posted do not show that, so...